PostgreSQL Wraparound Problemi Nedir?
Dünyada en çok tercih edilen veri tabanı sistemlerinden biri olan PostgreSQL’de dikkat edilmesi gereken sorunlardan biri de “wraparound”durumudur. Bu yazıda GTech Sistem ve Veri Tabanı Yönetimi Danışmanımız “wraparound” probleminin nasıl önleneceğini detaylarıyla anlattı.
PostgreSQL veri tabanlarında işlem gören tablolarda değiştirilen satırlar “dead tuple” olarak işaretlenir ve bu satırlar kullanım dışı kalır. Daha sonra “vacuum” adlı bakım işlemi ile bu “dead tuple”lar yeniden kullanılabilir olarak işaretlenir. Örneğin bir tabloda “delete” işlemi gerçekleştirildiğinde, silinen satır “dead tuple” olarak işaretlenir ve gizlenir. Bir güncelleme gerçekleştiğinde ise; PostgreSQL güncellenecek satırı kullanım dışı bırakıp gizler ve yeni halini “insert” eder. “Vacuum” kullanılmadığı taktirde bu uygulama yöntemi veri tabanı performansında ciddi düşüşlere yol açacaktır. “Vacuum” işlemi ile bu “dead tuple”lar yeniden kullanılabilir olarak işaretlenir ve disk üzerindeki “data page” temizlenir. Bu işlem diskte boş alan yaratmaz. PostgreSQL 8.3 versiyonu ile gelen “autovacuum” özelliği ile “vacuum” işlemi otomatik olarak çalışabilir hale gelmiştir. Özellikle veri tabanında yoğun “transaction” gerçekleşmeye başladığında “autovacuum”un devreye girdiğini görebilirsiniz.
Wraparound Nedir?
Yoğun kullanılan bir veri tabanımız olduğunu ve “autovacuum”u devre dışı bıraktığımızı düşünelim. Nihayetinde bu veri tabanı “Transaction ID” sayacınında limit değere ulaşacaktır. Bu değere ulaşıldığında, postgre’nin mimarisi olan Multi-Version Concurrency Control (MVCC) şematiği doğru şekilde çalışamamaya başlar ve “vacuum” işlemleri “DML” işlemlerine yetişemez. “Transaction ID” sayacı “transaction”lara “unique” değerler atamak için kullanılır ve alabileceği maksimum değer 4.2 milyardır. Limit değer ise 2 milyar seviyelerindedir, sayaç limite ulaştığında yeni işlemler için atanacak “unique” bir değer bulunamadığından veri tabanı aşağıdaki hatayı vermeye başlayacaktır:
Önlem alınmadığı taktirde “force shutdown” gerçekleşecek ve veri tabanı kapanacaktır. Bu, ciddi veri kayıplarına yol açabileceği için oldukça tehlikeli bir durumdur. Eğer “force shutdown” gerçekleşmezse geçmişte işlenmiş “transaction”lar gelecekte görünmeye başlayabilir ve silinmiş satırların geri gelmesi, güncellenmiş satırların eski haline dönmesi, yetki kısıtlama ihlalleri gibi anormal durumlarla karşılaşılabilir.
Vacuum İşlemi
“Vacuum”, “dead tuple” temizliği yapan bakım işlemidir. İki modu vardır;
Concurrent Vacuum
Herhangi bir erişim engeli oluşturmadan tablolardaki “dead tuple”ları temizler ve yeniden kullanılabilir olarak işaretler. “Vacuum” işlemi sonrasında diskte bir alan kazanımı olmaz.
Full Vacuum
“Concurrent vacuum”dan farklı olarak “full vacuum”, “dead tuple” olarak işaretli alanların çıkarıldığı yeni bir tablo oluşturur ve daha sonra eski tabloyu siler. “Full vacuum” uygulanan tablo “exclusive lock” ile kilitlenir ve “full vacuum” tamamlanana kadar bu tablo üzerinde bir sorgu çalıştırılamaz. “Full vacuum” işlemi sonrasında diskte alan kazanımı olur. Veri tabanının durumuna da bağlı olarak, uzun süredir “vacuum” çalıştırılmamış bir veri tabanında alan kazanımı daha fazla olacaktır.
Wraparound Problemi Nasıl Önlenir?
Her şeyden önce “autovacuum” kapatılmamalıdır, tüm tabloların düzenli şekilde “vacuum” işleminden geçtiğinden emin olunmalıdır. Doğru konfigüre edildiğinde çoğu durumda “autovacuum” yeterli olacaktır ancak bazı durumlarda manuel “vacuum” yapmak da gerekebilir. Bu nedenle sistem düzenli olarak izlenmelidir. Aşağıdaki “select” ile tabloların durumu gözlenebilir ve ihtiyaç duyulan tablo önceden fark edilip manuel “vacuum”” yapılarak “wraparound” probleminin önüne geçilebilir.
PostgreSQL veri tabanlarında “wraparound” problemini açıklayarak nasıl önlem alınacağına değindik. Yeni nesil teknolojilerimizle sunduğunuz Sistem ve Veri Tabanı Yönetimi çözümlerimiz hakkında bilgi almak için bize ulaşabilirsiniz.
Yazar: Mahmut Can Uçanefe, GTech Sistem ve Veri Tabanı Yönetimi Danışmanı
