PostgreSQL Logical Decoding (WAL Decoding)

Bu yazıda PostgreSQL’de WAL dosyalarından, veritabanında çalıştırılmış SQL’leri bind değerleri ile birlikte nasıl elde edebileceğimizi inceleyeceğiz. Veritabanında yapılan yanlış DELETE, UPDATE, INSERT işlemleri bu yöntem ile WAL dosyalarından çıkarılarak, hatalı işlemler geri alınabilirler. Logical Decoding özelliği PostgreSQL’e 11 sürümü ile gelmiştir. WAL dosyalarını inceleyebilmek için öncelikle bir replikasyon slotu oluşturmamız gereklidir. Slot ismi log_decode, çıktılar için test_decoding plug-in’i kullanıyoruz, false ile slot’un kalıcı olması gerektiğini belirtiyoruz. Bu fonksiyon bize slot’un başladığı LSN’i ve slot ismini geri döner. Slot’a ait bilgileri görelim. SELECT slot_name, plugin, slot_type, database, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots; Aşağıdaki sorgu ile slot üzerinden okuma yapmaya başlayabiliriz. Birinci parametresi slot adı, ikinci parametre (NULL verilmiş) upto_lsn, üçüncü parametre (NULL) upto_nchanges değerlerini ifade eder. Ancak bu iki parametre için NULL verilirse slot oluştuğundan güncel ana kadar olan değişiklikleri görebiliriz. Özel bir zaman aralığı veya belli sayıda değişiklik istenirse bu parametrelere değer verilebilir.  Gerçek ortam veritabanında sorgu sonucunda veriler anında […]

PostgreSQL Logical Decoding (WAL Decoding)

Bu yazıda PostgreSQL’de WAL dosyalarından, veritabanında çalıştırılmış SQL’leri bind değerleri ile birlikte nasıl elde edebileceğimizi inceleyeceğiz. Veritabanında yapılan yanlış DELETE, UPDATE, INSERT işlemleri bu yöntem ile WAL dosyalarından çıkarılarak, hatalı işlemler geri alınabilirler. Logical Decoding özelliği PostgreSQL’e 11 sürümü ile gelmiştir.

WAL dosyalarını inceleyebilmek için öncelikle bir replikasyon slotu oluşturmamız gereklidir.

Slot ismi log_decode, çıktılar için test_decoding plug-in’i kullanıyoruz, false ile slot’un kalıcı olması gerektiğini belirtiyoruz. Bu fonksiyon bize slot’un başladığı LSN’i ve slot ismini geri döner.

Slot’a ait bilgileri görelim.

SELECT slot_name, plugin, slot_type, database, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;

Aşağıdaki sorgu ile slot üzerinden okuma yapmaya başlayabiliriz. Birinci parametresi slot adı, ikinci parametre (NULL verilmiş) upto_lsn, üçüncü parametre (NULL) upto_nchanges değerlerini ifade eder. Ancak bu iki parametre için NULL verilirse slot oluştuğundan güncel ana kadar olan değişiklikleri görebiliriz. Özel bir zaman aralığı veya belli sayıda değişiklik istenirse bu parametrelere değer verilebilir.  Gerçek ortam veritabanında sorgu sonucunda veriler anında sorgudan döner. Ancak test ortamında DML yapılıncaya kadar sorgu boş sonuç döner.

SELECT * FROM pg_logical_slot_get_changes('log_decode', NULL, NULL);

Örnek bir tablo oluşturalım. DDL’ler replikasyona dahil olmadığından üstteki sorgu hala boş sonuç döner.

create table Users (id int, name text, surname text, email text);

Şimdi tabloya kayıt ekleyip silelim ve durumu inceleyelim.

insert into Users (id, name, surname, email) values (1, 'John', 'Ally', 'jalley@example.com');
insert into Users (id, name, surname, email) values (2, 'Bill', 'Gates', 'jalley@example.com');
insert into Users (id, name, surname, email) values (3, 'Henry', 'Ford', 'jalley@example.com');
insert into Users (id, name, surname, email) values (4, 'Mark', 'Sennt', 'jalley@example.com');

Yeniden slot’u sorgulayalım ve yaptığımız değişiklikleri görelim.

SELECT * FROM pg_logical_slot_get_changes('log_decode', NULL, NULL);

Sorguyu yeniden çalıştırdığımızda boş döndüğünü görürüz. Bunun nedeni, biz bu sorgu ile değişiklileri tüketen noktadayız (queue consumer). Son sorgumuzdan sonra değişiklik yoksa, sorgu sonucu boş gelir.

Eğer sorgulayınca sonuçların kalmasını istersek, farklı bir fonksiyonu aşağıdaki gibi kullanabiliriz. Şimdi bir kayıt daha ekleyelim ve sonuçlar kaybolmayacak şekilde sorgulayalım.

insert into Users (id, name, surname, email) values (6, 'Larry', 'Mock', 'jalley@example.com');

SELECT * FROM pg_logical_slot_peek_changes('log_decode', NULL, NULL, 'include-timestamp', 'on');

Yeniden sorgulayınca kayıtlar hala mevcut haldedir.

Fazla DML yapılan veritabanlarında çok fazla kayıt geleceği için sorgu sonucunu tabloya çıkarıp o tablo üzerinde işlemlere devam edilebilir. Çünkü her defasında WAL dosyalarından sonuçları çıkarıp göstermesi zaman alacaktır.

Benzer Yazılar

PostgreSQL’de pg_profile extension ile AWR oluşturma

PostgreSQL 7 ay önce

PostgreSQL veritabanını büyük sistemlerde yük altında kullanmaya başlayınca performansını izlemek ve tuning yapmak kaçınılmazdır. Ancak, PostgreSQL’de performansı izlemek için standart kurulum ile gelen özellikler yeterli değildir. Oracle’de bulunan AWR raporları gibi, sistemi en ince detayına kadar incelemek gerekebilir. Bu ihtiyaç için PostgreSQL için geliştirilen pg_profile extension’ı bulunmaktadır. Veritabanı iş yüklerini ve profilini çıkarabilmek için pg_profile aynı Oracle’de olduğu gibi snapshot’lar ve bu snapshot’lara üzerinden raporlar sunar. Bu yazıda pg_profile’ı nasıl kurup rapor alabileceğimizden bahsedeceğiz. Başka bir yazıda ise rapor incelemesi yapıp, olası tuning ihtimallerini değerlendireceğiz. Extension’a ait github sayfası : pg_profile pg_profile extension’ı kütüphane dosyası kullanmaz, bu yüzeden $PGHOME/lib altında *.so dosyası bulunmaz. Sadece veritabanında extension oluşturularak kullanılabilir. Github sayfasından PostgreSQL sürümüne uygun extension indirilerek sunucuya kopyalanır, sonrasında aşağıdaki gibi kurulur. sudo tar xzf pg_profile–4.2.tar.gz –directory $(pg_config –sharedir)/extension Extension oluşturma: postgres=# CREATE EXTENSION dblink; postgres=# CREATE EXTENSION pg_stat_statements; postgres=# CREATE SCHEMA profile; postgres=# CREATE EXTENSION pg_profile SCHEMA profile; Kullanmaya hazırız. […]

PostgreSQL’de WAL Boyutunu Değiştirme

PostgreSQL 7 ay önce

PostgreSQL veritabanında veritabanı değişikliklerinin yazıldığı dosyalara WAL (Write Ahead Log) ismi verilir. Birçok veritabanında farklı adlarda da olsa aynı yapı bulunmaktadır. Veritabanında yazma yükü fazla ise WAL dosyaları çok sık olarak yeni dosyaya geçmektedir (WAL Switch). Bu durum veritabanı performansına olumsuz etki yapar. PostgreSQL veritabanında WAL dosya büyüklükleri varsayılan olarak 16M olarak tanımlanmıştır. Bu günümüz iş yüklerini dikkate aldığımızda hayli küçük kalmaktadır. Bu yazıda WAL dosya boyutlarını nasıl değiştirebileceğimizden bahsedeceğiz.

0 Yorum

Yorum Yaz

Rastgele