EC2 - Bagaimana cara mencadangkan data PostgreSQL dengan benar?

Berikut adalah setup: 1 contoh kecil Amazon Linux (didukung EBS) EC2 dengan 3 volume tambahan. Ini adalah server web dan server basis data. Satu volume untuk kode, satu untuk direktori data PostgreSQL (8.4), dan satu volume untuk menyimpan file WAL dari PostgreSQL.

(1) Volume dengan file WAL juga akan memiliki basis cadangan dari direktori data, yang disalin setelah melakukan pg_start_backup (). Kemudian akan menyimpan hasil arsip kontinu dari PostgreSQL (file WAL). Untuk memotret volume ini, apakah ada gunanya mengeluarkan sinkronisasi dan membekukan sistem file (menggunakan xfs_freeze jika itu XFS atau dmsetup jika EXT4)? Atau bisakah saya mengambil snapshot langsung? File WAL akan dikirimkan dengan kecepatan satu per menit. Apakah mungkin snapshot dapat dimulai ketika satu file WAL sedang disalin dan mengakibatkan data yang rusak?

(2) Volume yang berisi direktori data PostgreSQL langsung juga akan didukung untuk ukuran yang baik (setiap hari). Sebelum melakukan snapshot volume ini, saya mengeluarkan pg_dump dan file SQL yang dihasilkan disimpan di direktori data. Apakah ada gunanya mengambil tindakan pencegahan untuk memastikan data database aktual konsisten? Apakah benar untuk mengasumsikan bahwa mengambil snapshot langsung akan dengan benar (a) file konfigurasi cadangan (postgresql.conf, pg_hba.conf, pg_ident.conf) dan (b) cadangan file dump SQL. Mencadangkan kedua hal tersebut, file dump sql dan file konfigurasi, akan menjadi poin utama snapshotting volume ini. DB tidak terlalu besar jadi saya tidak keberatan fakta bahwa file data akan mengasapi snapshot ini. Dan dalam hal ini, saya bisa melakukan snapshot langsung - benar?

(2a) Apakah lebih baik menyimpan direktori data pada volume root, dan memiliki skrip cadangan yang menyalin file dump sql serta mengkonfigurasi file ke volume lain, dan snapshot volume itu setelah salinan selesai?

(3) Adapun volume dengan kode di atasnya, lagi apakah ada gunanya sinkronisasi dan pembekuan sistem file? Atau dapatkah snapshot langsung diambil? Data ini harus cukup "statis".

(4) Apakah ini skema cadangan yang solid? Volume root tidak dicadangkan secara teratur karena saya hanya akan menyimpan gambar mesin setelah diatur dan dikonfigurasi.

Terima kasih

Lihat manual yang bagus . Jika saran saya bertentangan dengan 'dengan cara apa pun, itu benar.

1. Sinkronisasi bukanlah ide yang buruk, kecuali jika alat salin Anda fsync () adalah setiap file WAL yang ditulisnya dan direktori yang ada di dalamnya sebelum menyalin yang berikutnya. File WAL terakhir yang tidak lengkap tidak terlalu menjadi masalah; paling buruk, Anda cukup menghapusnya. Pg pada umumnya akan tersedak WAL yang tidak lengkap - meskipun tidak ada checksumming yang dilakukan, jadi Anda bisamenjadi benar-benar sial dan mencoba menerapkan data sampah yang kebetulan kebetulan terlihat seperti catatan WAL nyata. Di posisi Anda, saya akan menyinkronkan volume sebelum snapshot untuk memastikan buffer kotor yang tidak tertulis dalam RAM mengenai gambar sistem file pada disk. Pembekuan akan membantu menghindari WAL yang berantakan tapi tidak fatal sebagian ditulis, jadi itu bukan ide yang mengerikan tetapi tidak penting. Yang penting adalah memiliki timeline yang tidak rusak sampai titik pemulihan. Secara pribadi, saya menulis WAL saya ke nama file sementara dan mengganti nama mereka menjadi nama akhir mereka hanya sekali sepenuhnya disalin; jika Anda melakukan ini, Anda tidak perlu membeku.

2. Kedengarannya benar. Snapshot langsung sama seperti melakukan uji tarik steker pada sistem langsung dengan caching write-through. Basis data Anda akan pulih dengan baik ketika dikembalikan dari snapshot langsung, sama seperti setelah tarik-tusuk. Saya sarankan Anda mengotomatiskan pengujian pemulihan dari snapshot. (Catatan: Tes pemulihan snapshot bukan pengganti lengkap untuk pengujian steker karena tidak memperhitungkan kemungkinan disk, raid controller, dll. Caching tulis). Tidak hanya file konfigurasi dan dump, tetapi database sendiri harus baik-baik saja setelah foto Anda. Pertimbangkan untuk menyinkronkan volume sebelum foto untuk memastikan semua data dump dll benar-benar mengenai disk.
   
   2a. Mungkin menghemat ruang disk. Perbedaan kecil sebaliknya. Anda bisa menyimpan snapshot lebih lama tanpa semua churn dari database live.

3. Mengapa bahkan snapshot volume kode Anda? Salinan tingkat file biasa mungkin baik-baik saja. Pastinya snapshot langsung seharusnya.

4. Ini bukan skema cadangan yang solid. Gagal di satu area kritis: Tidak ada pengujian pemulihan dan validasi yang dilakukan. Anda harus selalu menguji cadangan Anda secara teratur untuk memastikan Anda benar-benar dapat memulihkannya.

   Secara pribadi, saya sarankan Anda menggunakan pengiriman WAL, atau mengirim dump database, ke host yang berbeda , lebih disukai yang tidak di Amazon EC2 atau setidaknya di wilayah yang berbeda. Tuan rumah ini harus melakukan tes pemulihan otomatis, mengirimkan laporan kepada Anda tentang hasilnya, dan juga harus diperiksa secara manual.

   Meskipun snapshots Anda (berisi dump) akan ada di S3, dan akan aman di sana, itu tidak berarti mereka akan dapat diakses ketika Anda membutuhkannya dengan segera. Klaim daya tahan Amazon meyakinkan, tetapi data Anda masih bisa aman dan sama sekali tidak dapat diakses oleh Anda selama pemadaman layanan S3 yang tidak tepat waktu.