Ada sesuatu yang menarik tentang pertanyaan ini - khususnya yang berkaitan dengan ide downtime. Bagian dari gagasan adalah bahwa jika suatu aplikasi sensitif terhadap downtime, maka waktu pemulihan juga harus diperhitungkan. (Sebagai argumen ekstrem, tidak ada cadangan yang tidak memerlukan downtime, kecuali jika Anda memerlukan cadangan tersebut, dalam hal ini downtime dapat mendekati tak terhingga ).
Sedikit tentang EBS
Volume dan snapshot EBS beroperasi pada level blok - konsekuensi yang memungkinkan snapshot diambil saat instance sedang berjalan, bahkan jika volume EBS sedang digunakan. Namun, hanya data yang benar-benar ada di disk (mis. Tidak dalam cache file) yang akan dimasukkan dalam snapshot. Alasan terakhir inilah yang memunculkan ide snapshot yang konsisten.
- Cara yang disarankan adalah melepaskan volume, snapshot, dan pasang kembali - biasanya tidak praktis.
- Pilihan terbaik berikutnya melibatkan pembilasan cache tulis ke disk, membekukan sistem file, dan mengambil snapshot Anda
Poin yang menarik di sini adalah bahwa dalam kedua kasus di atas, Anda tidak perlu menunggu snapshot selesai untuk menempel kembali / mencairkan dan melanjutkan penulisan ke disk - setelah snapshot dimulai, data Anda akan konsisten ke titik waktu tersebut. Biasanya ini hanya membutuhkan beberapa detik selama disk Anda terkunci. Juga karena kebanyakan basis data menyusun file-file mereka pada disk dengan cara yang masuk akal - ada kemungkinan besar bahwa insert memiliki efek minimal pada blok yang ada - yang meminimalkan data yang ditambahkan ke snapshot.
Pertimbangkan titik cadangan
Volume EBS sudah direplikasi dalam zona ketersediaan - jadi ada tingkat redundansi yang tertanam. Jika instance Anda berakhir, Anda dapat dengan mudah melampirkan volume EBS ke instance baru dan (setelah Anda melewati kurangnya konsistensi) melanjutkan di mana Anda tinggalkan. Dalam banyak hal ini membuat volume EBS sangat mirip dengan snapshot yang tidak konsisten, asalkan Anda dapat mengaksesnya. Yang mengatakan, sebagian besar pengguna EC2 mungkin mengingat kegagalan cascading volume EBS dari awal 2011 - volume tidak dapat diakses selama beberapa hari, dan beberapa pengguna kehilangan data juga.
RAID1
Jika Anda mencoba melindungi terhadap kegagalan disk EBS (itu memang terjadi), Anda dapat mempertimbangkan pengaturan RAID1. Karena volume EBS adalah perangkat blok, Anda dapat dengan mudah menggunakan mdadm untuk mengaturnya dalam konfigurasi yang Anda inginkan. Jika salah satu volume EBS Anda tidak berfungsi untuk spec, cukup mudah untuk secara manual gagal (dan kemudian menggantinya dengan volume EBS lain). Tentu saja, ini memiliki kerugian - peningkatan waktu untuk setiap penulisan, kerentanan yang lebih besar untuk kinerja variabel, dua kali lipat biaya I / O (monetariliy, bukan kinerja-bijaksana), tidak ada perlindungan nyata terhadap kegagalan AWS yang lebih luas (masalah umum tahun lalu adalah ketidakmampuan untuk melepaskan volume EBS yang dalam kondisi terkunci), dan tentu saja, kondisi disk yang tidak konsisten pada kegagalan.
S3FS
Opsi untuk aplikasi tertentu (jelas BUKAN untuk basis data) adalah memasang S3 sebagai sistem file lokal (mis. Via s3fs). Ini lambat, tidak memiliki beberapa fitur yang diharapkan dari sistem file, dan mungkin tidak berperilaku seperti yang diharapkan (akhirnya konsistensi). Yang mengatakan, untuk tujuan sederhana seperti membuat file yang diunggah tersedia di seluruh instance, mungkin pantas. Jelas itu bukan untuk apa pun yang membutuhkan kinerja baca / tulis yang baik.
Bin-log MySQL
Satu lagi opsi khusus untuk MySQL adalah penggunaan bin-log. Anda dapat mengatur volume EBS kedua yang akan menyimpan bin-log Anda (untuk meminimalkan efek penulisan yang ditambahkan pada database Anda), dan menggunakannya bersamaan dengan dump database apa pun yang Anda ambil. Anda bahkan mungkin dapat melakukan ini dengan s3fs, yang mungkin sebenarnya memiliki manfaat jika kinerjanya lumayan (sebuah rsync mungkin akan lebih baik meskipun daripada mencoba menggunakan s3fs secara langsung, dan Anda pasti ingin mengompres apa yang Anda bisa).
Namun, sekali lagi, kita kembali ke gagasan tentang tujuan. Pertimbangkan apa yang akan terjadi dengan saran di atas:
- Volume EBS tidak dapat diakses:
- RAID1 - tidak berguna, karena Anda tidak dapat mengakses data
- bin-log - tidak berguna, kecuali jika Anda mengekspornya ke S3 - mungkin penundaan jika Anda melakukannya
- Mesin virtual berhenti tiba-tiba:
- RAID1 - disk Anda tersedia, tetapi tidak konsisten, database Anda dapat pulih dari ketidakkonsistenan sendiri
- bin-log - data Anda harus dapat diakses, meskipun Anda mungkin perlu meninjau beberapa peristiwa terakhir
- Seseorang menjalankan DATABASE DROP sebagai root:
- RAID1 - Anda memiliki dua salinan sempurna dari database yang tidak ada
- bin-log - Anda harus dapat memutar ulang acara hingga sebelum perintah, jadi Anda harus baik-baik saja
Jadi sungguh, RAID1 sebagian besar tidak berguna, dan bin-log terlalu lama - keduanya mungkin pantas dalam keadaan tertentu, tetapi jauh dari ide cadangan.
Jepretan
Penting untuk dicatat bahwa snapshot berbeda, dan hanya menyimpan blok aktual yang berisi data (dan dikompresi). Berbeda dengan volume EBS, di mana jika Anda memiliki volume 20GB, tetapi hanya menggunakan 1GB, Anda masih dikenakan biaya untuk penyimpanan 'yang disediakan' (20GB). Dengan snapshot, Anda hanya dikenai biaya untuk apa yang Anda gunakan. Jika tidak ada data yang berubah di antara foto, ada (secara teoritis) tidak ada biaya. (Snapshots dikenai biaya PUTS / GETS dan penyimpanan bekas).
Sebagai tambahan, saya akan sangat merekomendasikan data aplikasi Anda (termasuk database) tidak disimpan pada volume root Anda (yang mungkin sudah Anda siapkan). Salah satu keuntungannya adalah, semoga saja, volume root Anda melihat perubahan minimum - artinya snapshots-nya bisa lebih jarang (atau akan memiliki perubahan minimum) mengurangi biaya dan kemudahan penggunaan.
Juga relevan untuk menyebutkan bahwa Anda dapat menghapus snapshot lama kapan saja - walaupun mereka berbeda, mereka tidak akan memengaruhi snapshot lainnya. Karena itu, setiap blok yang dialokasikan untuk snapshot tidak akan dilepaskan sampai tidak ada snapshot yang masih merujuk pada blok itu.
Masalah dengan dump berkala adalah pertama kali antara dump (mungkin ditangani dengan menggunakan bin-log MySQL) dan juga kesulitan pemulihan. Butuh waktu untuk mengimpor dump besar dan memutar ulang semua peristiwa dari sebuah log-bin. Juga, membuat dump bukan tanpa implikasi kinerjanya. Dapat diperdebatkan, dump seperti itu kemungkinan membutuhkan penyimpanan yang jauh lebih besar daripada snapshot. Menyiapkan volume EBS semata-mata untuk database dan snapshotting yang lebih disukai dalam banyak hal (yang mengatakan, mengambil snapshot memang memiliki sedikit implikasi kinerja juga).
Keindahan snapshot dan volume EBS adalah mereka dapat digunakan pada contoh lain. Jika instance Anda gagal untuk boot, Anda dapat melampirkan volume root ke instance lain untuk mendiagnosis dan memperbaiki masalah - atau hanya menyalin data Anda dari itu - dan dapat mengganti volume root dengan hanya beberapa menit downtime (hentikan instance, lepas volume root, lampirkan volume root baru, mulai instance). Gagasan yang sama ini berlaku untuk memiliki data Anda pada volume EBS kedua. Pada dasarnya, Anda hanya memutar instance baru dari AMI khusus Anda, dan melampirkan volume EBS Anda saat itu - itu membantu meminimalkan downtime.
(Seseorang dapat membuat argumen (dan saya mungkin tidak akan merekomendasikannya) bahwa Anda dapat mengatur dua salinan MySQL pada server yang sama (Master-slave), menggunakan dua volume EBS, dan kemudian mematikan budak Anda untuk mengambil snapshot-nya Volume EBS - ini akan konsisten, tanpa downtime - tetapi biaya kinerja kemungkinan tidak sepadan).
AWS memang memiliki autoscaling - yang akan dapat mempertahankan jumlah instance yang konstan (bahkan jika jumlahnya 1) - Anda akan menggunakan dari snapshot namun - jadi jika snapshot Anda tidak berguna, maka premis tidak banyak digunakan .
Beberapa poin lain - Anda dapat menggunakan sebanyak mungkin instance dari satu snapshot (tidak seperti volume EBS, yang hanya dapat dilampirkan ke satu instance pada waktu tertentu). Juga, volume EBS dibatasi untuk digunakan dalam zona ketersediaan, sementara snapshot dapat digunakan dalam suatu wilayah.
Idealnya, dengan snapshot, jika server Anda mati, Anda bisa meluncurkan yang baru menggunakan snapshot terakhir - terutama jika Anda memisahkan volume root Anda dari data Anda, pembaruan yang buruk akan menghasilkan minimum downtime (karena Anda hanya akan transfer volume EBS yang berisi data Anda - dan ambil snapshot untuk menjaga apa pun yang mungkin rusak karena inkonsistensi).
Sebagai catatan tambahan, Amazon menyatakan tingkat kegagalan volume EBS meningkat dengan jumlah data yang diubah sejak foto terakhir.
Rekomendasi akhir
- Gunakan snapshot - mereka hebat - mereka mengurangi waktu henti lebih banyak daripada yang menyebabkannya
- Pisahkan data dan volume root, bahkan mungkin menempatkan basis data pada volume mereka sendiri, dan snapshot sebelum pembaruan jika perlu
- Gunakan bin-log untuk tetap 'panas' mungkin - unggah ini (dikompresi) ke S3
- Pastikan Anda benar-benar mendapatkan data dari instance (bahkan jika data utuh pada volume EBS, volume itu sendiri mungkin sementara tidak dapat diakses).
Bacaan yang Disarankan:
(Saya yakin saya telah menulis terlalu banyak, tetapi tidak cukup mengatakan - tetapi mudah-mudahan Anda menemukan sesuatu yang layak dibaca).