View a markdown version of this page

Keandalan Amazon Aurora - Amazon Aurora
Perbaikan penyimpanan otomatisCache halaman yang dapat bertahanPemulihan dari pengaktifan ulang yang tidak direncanakan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Keandalan Amazon Aurora

Aurora dirancang untuk menjadi andal, durabel, dan toleran terhadap kesalahan. Anda dapat menentukan arsitektur klaster DB Aurora Anda untuk meningkatkan ketersediaan dengan melakukan hal-hal seperti menambahkan Replika Aurora dan menempatkannya di Zona Ketersediaan yang berbeda-beda, dan Aurora juga menyertakan beberapa fitur otomatis yang menjadikannya solusi basis data yang andal.

Perbaikan penyimpanan otomatis

Karena Aurora menyimpan beberapa salinan data Anda di tiga Zona Ketersediaan, kemungkinan kehilangan data akibat kegagalan disk dapat diminimalkan secara signifikan. Aurora secara otomatis mendeteksi kegagalan dalam volume disk yang membentuk volume klaster. Saat sebuah segmen volume disk gagal, Aurora segera memperbaiki segmen tersebut. Saat Aurora memperbaiki segmen disk, Aurora menggunakan data dalam volume lain yang membentuk volume klaster untuk memastikan bahwa data dalam segmen yang diperbaiki sudah diperbarui. Dengan begitu, Aurora menghindari kehilangan data dan mengurangi kebutuhan untuk melakukan pemulihan titik waktu untuk memulihkan dari kegagalan disk.

Cache halaman yang dapat bertahan

Di Aurora, cache halaman instans DB dikelola dalam proses terpisah dari basis data, yang memungkinkan cache halaman bertahan secara terpisah dari basis data. (Cache halaman juga disebut pool buffer InnoDB di Aurora MySQL dan cache buffer pada Aurora PostgreSQL).

Jika terjadi kegagalan basis data yang tidak terduga, cache halaman tetap berada di memori, sehingga halaman data saat ini tetap dalam kondisi “warm” di cache halaman saat basis data diaktifkan kembali. Ini memberikan keuntungan kinerja dengan melewati kebutuhan kueri awal untuk menjalankan I/O operasi baca untuk “menghangatkan” cache halaman.

Untuk Aurora MySQL, perilaku cache halaman saat boot ulang dan gagal adalah sebagai berikut:

  • Anda dapat me-reboot instance penulis tanpa me-reboot instance pembaca.

    • Jika instans pembaca tidak melakukan boot ulang saat instans penulis melakukan boot ulang, instans tersebut tidak kehilangan cache halamannya.

    • Jika instans pembaca melakukan boot ulang saat instans penulis melakukan boot ulang, instans tersebut kehilangan cache halamannya.

  • Ketika instans pembaca melakukan boot ulang, halaman cache pada instans penulis dan pembaca sama-sama bertahan.

  • Ketika klaster DB gagal, efeknya mirip dengan ketika instans penulis melakukan boot ulang. Pada instans penulis baru (sebelumnya instans pembaca) cache halaman bertahan, tetapi pada instans pembaca (sebelumnya instans penulis), cache halaman tidak bertahan.

Untuk Aurora PostgreSQL, Anda dapat menggunakan manajemen cache klaster untuk mempertahankan cache halaman dari instans pembaca yang ditetapkan yang menjadi instans penulis setelah failover. Untuk informasi selengkapnya, lihat Pemulihan cepat setelah failover dengan manajemen cache klaster untuk Aurora PostgreSQL.

Pemulihan dari pengaktifan ulang yang tidak direncanakan

Aurora dirancang untuk pulih dari pengaktifan ulang yang tidak direncanakan hampir seketika dan terus melayani data aplikasi Anda tanpa log biner. Aurora pulih secara asinkron pada thread paralel, sehingga basis data Anda terbuka dan tersedia segera setelah pengaktifan ulang yang tidak direncanakan.

Untuk informasi selengkapnya, lihat Toleransi kesalahan untuk klaster DB Aurora dan Optimisasi untuk mengurangi waktu pengaktifan ulang basis data..

Berikut ini adalah pertimbangan untuk pencatatan log biner dan pemulihan pengaktifan ulang yang tidak direncanakan di Aurora MySQL:

  • Mengaktifkan log biner di Aurora secara langsung memengaruhi waktu pemulihan setelah pengaktifan ulang yang tidak direncanakan, karena hal itu memaksa instans DB untuk melakukan pemulihan log biner.

  • Jenis pencatatan log biner yang digunakan memengaruhi ukuran dan efisiensi pencatatan log. Untuk jumlah aktivitas basis data yang sama, beberapa format mencatat log untuk lebih banyak informasi dibandingkan yang lain dalam log biner. Pengaturan berikut untuk parameter binlog_format menghasilkan jumlah data log yang berbeda:

    • ROW – Data log paling banyak

    • STATEMENT – Data log paling sedikit

    • MIXED – Data log dalam jumlah sedang yang biasanya memberikan kombinasi integritas data dan performa yang terbaik

    Jumlah data log biner memengaruhi waktu pemulihan. Jika ada lebih banyak data yang dicatat lognya dalam log biner, instans DB harus memproses lebih banyak data selama pemulihan, yang meningkatkan waktu pemulihan.

  • Untuk mengurangi overhead komputasi dan meningkatkan waktu pemulihan dengan pencatatan log biner, Anda dapat menggunakan binlog yang disempurnakan. Binlog yang disempurnakan mempersingkat waktu pemulihan basis data hingga 99%. Untuk informasi selengkapnya, lihat Menyiapkan binlog yang disempurnakan untuk Aurora MySQL.

  • Aurora tidak memerlukan log biner untuk mereplikasi data dalam klaster DB atau melakukan pemulihan titik waktu (PITR).

  • Jika Anda tidak membutuhkan log biner untuk replikasi eksternal (atau log stream biner eksternal), kami sarankan Anda mengatur parameter binlog_format ke OFF untuk menonaktifkan log biner. Hal ini mengurangi waktu pemulihan.

Untuk informasi selengkapnya tentang pencatatan log biner dan replikasi Aurora, lihat Replikasi dengan Amazon Aurora. Untuk informasi tentang implikasi tipe replikasi MySQL yang berbeda-beda, lihat Advantages and disadvantages of statement-based and row-based replication dalam dokumentasi MySQL.