Snapshots penyimpanan untuk pencadangan postgresql yang konsisten - volume data dan log berbeda

Kami menjalankan banyak Linux VM di lingkungan penyimpanan vmware / shared, masing-masing menjalankan instance postgreSQL (campuran 9.0 dan 9.3). Saat ini, seluruh VM duduk di satu partisi root / volume, dan kami telah sukses besar (~ 8 tahun) menggunakan snapshot berbasis penyimpanan volume VMFS yang mendasari untuk proses backup / restore (dan replikasi ke situs DR kami).

Karena arsitektur dari penyimpanan kami, akan menguntungkan untuk memisahkan file-file WAL postgres dengan volume yang tidak di-cache, sebagian besar-tulis untuk memberi kami lebih sedikit cache cache di sisi penyimpanan. Dengan penyimpanan kami (Nimble Storage), kami dapat menetapkan kedua volume ke grup proteksi / snapshot tunggal, tetapi saya belum dapat memperoleh dari vendor kami bahwa snapshot akan terjadi secara tepat pada saat yang sama di semua volume dalam grup proteksi - sepertinya akan, tetapi selalu ada kemungkinan milidetiknya terpisah.

Untuk itu, kami menjalankan beberapa percobaan, semua sambil menulis data ke DB secepat mungkin menggunakan pg_bench. Setelah percobaan, kami mengembalikan volume snapshot kami dan memulai postgres VM +

• Jepret baik data dan volume log dekat secara bersamaan - hasil: DB pulih
• Volume data foto pertama, volume log ~ 1 menit kemudian - hasil: DB pulih
• Volume log foto pertama, volume data ~ 1 menit kemudian - hasil: DB pulih
• Volume log snapshot pertama, volume data ~ 3 menit kemudian, setelah pos pemeriksaan WAL menulis data baru ke datafiles: hasil: DB pulih

Jadi pengujian tampaknya memberi tahu kami selama kedua snapshot konsisten pada tingkat volume, dan relatif berdekatan, Anda mendapatkan salinan DB yang konsisten, berdasarkan pada saat snapshot volume WAL / Log.

Pertanyaan saya: Apakah ini aman? Apa kasus sudut yang kami lewatkan dalam pengujian kami, dan apa yang bisa salah?

Dokumen Postgres menunjukkan ini tidak aman, tetapi pengujian tampaknya menunjukkan cukup kuat: http://www.postgresql.org/docs/9.1/static/backup-file.html

Jika database Anda tersebar di beberapa sistem file, mungkin tidak ada cara untuk mendapatkan snapshot beku simultan dari semua volume. Misalnya, jika file data dan log WAL Anda ada di disk yang berbeda, atau jika tablespace berada di sistem file yang berbeda, mungkin tidak mungkin untuk menggunakan cadangan snapshot karena snapshot harus simultan. Baca dokumentasi sistem file Anda dengan sangat hati-hati sebelum memercayai teknik snapshot konsisten dalam situasi seperti itu.

CATATAN: Ya, kami tahu tentang opsi lain untuk memastikan mereka konsisten, seperti menempatkan PostgreSQL ke mode cadangan panas atau menggunakan integrasi VMware penyimpanan kami untuk menenangkan VM itu sendiri, tetapi kami mencari solusi hanya penyimpanan untuk kecepatan, kenyamanan, dan tidak ada dampak pada klien kami.

Dokumentasi yang Anda kutip mengatakan semuanya, tetapi saya tidak akan menyalahkan Anda jika Anda ingin memverifikasi klaim vendor mengenai snapshot yang diambil secara bersamaan. Mungkin cara mengungkap sesuatu bisa dengan menekankan menguji sistem WAL lebih khusus.

misalnya Selain tes berbasis pgbench Anda, coba tambahkan panggilan acak pg_switch_xlog()untuk memaksa rotasi log, interval pos pemeriksaan lebih pendek dan lebih lama (memperpendek dan memperpanjang checkpoint_timeoutdan checkpoint_timeout) dan bahkan menggunakan ukuran file wal kecil atau besar.

Kecuali ada sesuatu yang saya lewatkan, karena foto-foto Anda tidak diambil pada waktu yang bersamaan, saya akan mengaitkan DB Anda yang telah pulih mungkin dengan sedikit waktu yang beruntung. Dalam kasus terakhir, bayangkan Anda mengambil snapshot log Anda saat lokasi xlog saat ini adalah, katakanlah 0/A1C0FFEE,. Kemudian Anda memiliki 3 menit beban sangat berat pada sistem, yang menyebabkan siklus penuh melalui file WAL, dan DB Anda sekarang berada di 0/DEADBEEFsaat snapshot data diambil. Ketika Anda mencoba untuk memulihkan, file WAL yang sedang ditulis pada saat snapshot data sudah lama hilang, dan pemulihan akan gagal.