PG_STAT_IO İLE VERİ TABANI KÜMÜLATİF I/O İSTATİSTİKLERİNİN İNCELENMESİ
PostgreSQL 16 versiyonu ile birlikte gelen pg_stat_io, veri tabanlarındaki I/O ilişkili işlemlere ait istatistikleri kümülatif olarak ve tüm cluster için gösteren, doğru kullanıldığında ve yorumlandığında oldukça faydalı olabilecek bir view. View içerisinde I/O işlemleri backend process türlerine göre gruplanmış olarak gösteriliyor, örneğin veri tabanına bağlantı kuran kullanıcıların işlemlerine ilişkin istatistikler “backend_type”=”client backend” şeklinde bir arada gösteriliyor. Diğer bir kolon “context” ise I/O işleminin içeriğini, bir diğer anlamda çeşidini belirtiyor ve “normal”, “vacuum”, “bulkread”, “bulkwrite” değerlerini alabiliyor. View kolonları ile ilgili detaylı bilgiyi buradan inceleyebilirsiniz. Yazımızda pg_stat_io view’ının sunduğu içeriği daha iyi anlayabilmek adına, basit işlemler sonucu ortaya çıkan istatistikleri inceleyeceğiz.
POSTGRESQL 17’DE PG_STAT_BGWRITER VE PG_STAT_CHECKPOINTER ANALİZİ
pg_stat_bgwriter ve pg_stat_checkpointer view’larının özelliklerini ve process’lerin davranışlarını inceleyeceğimiz bu yazımıza öncelikle konunun geçmişinden bahsederek başlayalım. Daha öncesinde “Background Writer” (bgwriter) process’inin görevi olan “background write” ve “checkpoint” işlemleri PostgreSQL 9.2 versiyonunda iki ayrı process’e bölündü ve “background write” işlemini bgwriter, checkpoint işlemini de checkpointer process’i yapacak şekilde güncellendi. (9.2 versiyonundan önce checkpointer process’i yoktu). Bu değişikliğin en önemli nedenlerinden biri şu linkte de görebileceğiniz gibi checkpoint’in son fsync işlemini yapabilmek için “background write” işlemini durdurma zorunluluğuydu ve bunun gibi faktörler negatif performans etkisi yaratıyor idi. 9.2 versiyonunda bahsettiğimiz değişiklik yapıldı ve checkpointer process’i devreye alındı, ancak background process’lerde yapılan bu değişiklik, istatistik view’larına yansımadı ve her iki process’e ait bilgiler pg_stat_bgwriter view’ında tutulmaya devam etti. PostgreSQL 17 versiyonunda ise bu istatistikler de artık farklı view’larda tutulmaya başlandı.
POSTGRESQL’DE CRASH RECOVERY MEKANİZMASINI ETKİLEYEN FAKTÖRLER
OLTP veri tabanlarından beklentimiz sistemin ani/beklenmedik kapanmasından sonra tekrar veri kayıpsız ve tutarlı bir şekilde, yani commit edilmiş işlemlerin tamamlandığı, commit edilmemiş işlemlerin geri alındığı bir şekilde tekrar açılmasıdır. Bu işleme crash recovery ismini veriyoruz ve PostgreSQL’de crash recovery mekanizmasının merkezinde WAL (Write Ahead Log) var. PostgreSQL, bahsettiğimiz beklentiyi karşılamak için gerekli tüm yeteneğe WAL sistemi sayesinde sahip, ancak bir PostgreSQL veri tabanında bu işlemin sorunsuz tamamlanacağını, veri tabanının her kapanışta tutarlı ve veri kayıpsız açılacağını söyleyebilmek için bazı konfigürasyonları incelemek gerekli. Bu yazıda crash recovery mekanizmasını etkileyecek parametreler, varlık sebepleri ve konfigürasyon opsiyonlarını inceleyeceğiz.
POSTGRESQL MAJÖR UPGRADE YÖNTEMLERİ
PostgreSQL veri tabanlarınızda majör versiyon yükseltmesi yapmanız için 3 farklı yöntem mevcut. Bunlar :
- pg_dumpall ile tüm verinin hedef versiyonda yaratılmış bir veritabanı cluster’ına taşınması
- pg_upgrade ile system tablolarının yenilenmesi ve kullanıcı verilerinin olduğu gibi kullanılması
- Logical replication ile tüm verinin standby ortamda yeni versiyona taşınması ve switch-over ile rol değişimi yapılması.
Bu yöntemlerin avantaj/dezavantajları anlamında hızlıca üzerlerinden geçelim.