Postgresql'in tutarlı bir şekilde yedeklenmesi için depolama anlık görüntüleri - farklı veri ve günlük hacimleri


11

Her biri kendi postgreSQL örneğini (9.0 ve 9.3 karışımı) kullanan bir vmware / paylaşılan depolama ortamında birçok Linux VM'si çalıştırıyoruz. Şu anda, tüm VM tek bir kök bölüme / birime oturur ve yedekleme / geri yükleme işlemi (ve DR sitemize çoğaltma) için temel VMFS birimlerinin depolama tabanlı anlık görüntülerini kullanarak büyük bir başarı elde ettik (~ 8 yıl).

Depolama alanımızın mimarisi nedeniyle, depolama tarafında daha az önbellek karmaşası sağlamak için postgres WAL dosyalarını önbelleğe alınmamış, çoğunlukla yazma birimine ayırmak avantajlı olacaktır. Depolama alanımızla (Çevik Depolama), her iki birimi de tek bir koruma / anlık görüntü grubuna atayabiliriz, ancak tedarikçimizden, anlık görüntülerin koruma grubundaki tüm birimlerde aynı anda OLACAĞINI sağlayamadım. - Muhtemelen olacak, ama her zaman milisaniye aralıklı olma şansı var.

Bu amaçla, pg_bench kullanarak DB'ye mümkün olduğunca hızlı veri yazarken bazı deneyler yaptık. Deneylerden sonra, anlık görüntü birimlerimizi geri yükledik ve VM + postgres'i başlattık

  • Hem veri hem de günlük hacimlerini aynı anda yakınlaştı - sonuç: DB kurtarıldı
  • Önce anlık görüntü veri hacmi, günlük hacmi ~ 1 dakika sonra - sonuç: DB kurtarıldı
  • Önce anlık görüntü günlüğü hacmi, veri hacmi ~ 1 dakika sonra - sonuç: DB kurtarıldı
  • WAL denetim noktasının veri dosyalarına yeni veriler yazmasından sonra ilk olarak anlık görüntü günlüğü birimi, veri hacmi ~ 3 dakika sonra: sonuç: DB kurtarıldı

Bu nedenle, her iki anlık görüntü de ses düzeyinde tutarlı olduğu ve nispeten birbirine yakın olduğu sürece, testin WAL / Log hacim anlık görüntüsünün zamanına bağlı olarak DB'nin tutarlı bir kopyasını aldığınız anlaşılıyor.

Sorum: Bu güvenli mi? Testlerimizde eksik olduğumuz köşe durumlar nelerdir ve ne ters gidebilir?

Postgres'in dokümanı bunun güvenli olmadığını gösteriyor, ancak testler oldukça sağlam olduğunu gösteriyor: http://www.postgresql.org/docs/9.1/static/backup-file.html

Veritabanınız birden fazla dosya sistemine yayılmışsa, tüm birimlerin tam olarak eşzamanlı dondurulmuş anlık görüntülerini elde etmenin bir yolu olmayabilir. Örneğin, veri dosyalarınız ve WAL günlüğünüz farklı disklerdeyse veya tablo alanları farklı dosya sistemindeyse, anlık görüntüler eşzamanlı olması gerektiğinden anlık görüntü yedeklemesi kullanmak mümkün olmayabilir. Bu gibi durumlarda tutarlı anlık görüntü tekniğine güvenmeden önce dosya sistemi belgelerinizi dikkatle okuyun.

NOT: Evet, tutarlı olmalarını sağlamak için PostgreSQL'i sıcak yedekleme moduna sokmak veya sanal makinelerin kendilerini sorgulamak için depolama alanımızın VMware entegrasyonunu kullanmak gibi diğer seçenekleri biliyoruz, ancak hız, kolaylık, ve müşterilerimize sıfır etki.


2
Bir güncelleme - depolama tedarikçimiz Nimble Storage, bugün bir koruma grubunun parçası olarak alınan anlık görüntülerin gerçekten de hacimler arasında tutarlı olduğunu / tam zamanında aynı noktada alındığını söyledi. Ancak - Test Postgres'imizde aynı anda alınmayan anlık görüntülerden kurtulmak için yeterince güçlü görünüyor gibi, herhangi bir yorum varsa hala ilgilenirim.
Steve

"Önce anlık görüntü veri hacmi, günlük hacmi ~ 1 dakika sonra" derseniz ne demek, hem veri hem de günlük hacmi aynı anlık görüntü grubundaysa, aynı anda yapılacaktır. verileri ve günlük hacmini bir anlık görüntü grubuna koyun ve anlık görüntüyü yapın, ardından DB'yi bu anlık görüntüden geri yükleme, bir örnek kilitlenme kurtarması gibi. Daha önce Oracle için anlık görüntü teknolojisi ile EMC depolama tabanlı yedeklemeyi test ediyordum. Çok güvenilir.
fairybetty

Yanıtlar:


2

Belirttiğiniz belgeler her şeyi söylüyor, ancak aynı anda alınan anlık görüntülerle ilgili olarak satıcının iddialarını doğrulamak istiyorsanız sizi suçlamam. Belki de bir şeyi ortaya çıkarmanın bir yolu, WAL sistemini daha spesifik olarak test etmek olabilir .

Örneğin, pgbench tabanlı testlerinize ek olarak, pg_switch_xlog()günlük dönüşünü, daha kısa ve daha uzun kontrol noktası aralıklarını (kısaltma ve uzatma checkpoint_timeoutve checkpoint_timeout) zorlamak için rastgele çağrılar eklemeyi ve hatta küçük veya büyük wal dosya boyutlarını kullanmayı deneyin .

Eksik olduğum bir şey olmadığı sürece, anlık görüntüleriniz aynı anda alınmadığı için, kurtarılan DB'lerinizi belki de biraz şanslı zamanlamaya bağlarım. Son durumda, geçerli xlog konumu diyelim ki, günlük anlık görüntünüzü aldığınızı düşünün 0/A1C0FFEE. Ardından, sistemde 3 dakikalık, özellikle WAL dosyaları arasında tam bir döngüye neden olan ağır yükünüz var 0/DEADBEEFve veri anlık görüntüsü alınırken DB'niz şimdi . Geri yüklemeye çalıştığınızda, veri anlık görüntüsü alınırken yazılan WAL dosyaları çoktan kaybolur ve kurtarma başarısız olur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.