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. Akibatnya, Aurora menghindari kehilangan data dan mengurangi kebutuhan untuk melakukan point-in-time pemulihan 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 kumpulan buffer InnoDB di Aurora My SQL dan cache buffer di Aurora Postgre.) SQL

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. Hal ini memberikan peningkatan performa dengan meniadakan kebutuhan kueri awal untuk mengeksekusi operasi I/O untuk melakukan “warming” cache halaman.

Untuk Aurora MySQL, perilaku cache halaman saat me-reboot 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 cluster untuk mempertahankan cache halaman dari instance pembaca yang ditunjuk yang menjadi instance 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, silakan lihat Toleransi kesalahan untuk klaster DB Aurora dan Optimisasi untuk mengurangi waktu pengaktifan ulang basis data..

Berikut ini adalah pertimbangan untuk pencatatan biner dan pemulihan restart yang tidak direncanakan di Aurora My: SQL

  • 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 My SQL.

  • Aurora tidak memerlukan log biner untuk mereplikasi data dalam cluster DB atau untuk melakukan point-in-time restore (). 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 selengkapnya tentang implikasi berbagai jenis SQL replikasi Saya, lihat Keuntungan dan kerugian replikasi berbasis pernyataan dan berbasis baris dalam dokumentasi Saya. SQL