Penyimpanan dan keandalan Amazon Aurora - Amazon Aurora
Gambaran umum penyimpanan AuroraKonten volume klasterKonfigurasi penyimpanan klaster AuroraBagaimana penyimpanan berubah ukuranPenagihan dataKeandalan

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

Penyimpanan dan keandalan Amazon Aurora

Di bagian berikut ini, Anda dapat mempelajari tentang subsistem penyimpanan Aurora. Aurora menggunakan arsitektur penyimpanan terdistribusi dan bersama yang merupakan faktor penting dalam performa, skalabilitas, dan keandalan klaster Aurora.

Gambaran umum penyimpanan Amazon Aurora

Data Aurora disimpan di volume klaster, yang merupakan volume virtual tunggal yang menggunakan solid state drive (SSD). Volume klaster terdiri dari salinan data di tiga Zona Ketersediaan dalam satu Wilayah AWS. Karena data direplikasi secara otomatis di Zona ketersediaan, data Anda sangat durabel dengan kemungkinan kehilangan data yang kecil. Replikasi ini juga mempertahankan ketersediaan basis data Anda selama failover. Hal itu terjadi karena salinan data sudah ada di Zona Ketersediaan lain dan terus melayani permintaan data ke instans DB dalam klaster DB Anda. Jumlah replikasi bergantung pada jumlah instans DB dalam klaster Anda.

Aurora menggunakan penyimpanan lokal terpisah untuk file sementara yang tidak persisten. Ini termasuk file yang digunakan untuk tujuan seperti mengurutkan set data besar selama pemrosesan kueri, dan membuat indeks. Lihat informasi yang lebih lengkap di Batas penyimpanan sementara untuk Aurora MySQL dan Batas penyimpanan sementara untuk Aurora PostgreSQL.

Apa saja konten volume klaster

Volume klaster Aurora berisi semua data pengguna, objek skema, dan metadata internal seperti tabel sistem dan log biner. Misalnya, Aurora menyimpan semua tabel, indeks, objek besar biner (BLOB), prosedur tersimpan, dan seterusnya untuk klaster Aurora dalam volume klaster.

Arsitektur penyimpanan bersama Aurora membuat data Anda terpisah dari instans DB di dalam klaster. Misalnya, Anda dapat menambahkan instans DB dengan cepat karena Aurora tidak membuat salinan data tabel yang baru. Sebagai gantinya, instans DB terhubung ke volume bersama yang sudah berisi semua data Anda. Anda dapat menghapus instans DB dari suatu klaster tanpa menghapus data dasar dari klaster tersebut. Aurora hanya akan menghapus data jika Anda menghapus seluruh klaster tersebut.

Konfigurasi penyimpanan untuk klaster DB Amazon Aurora

Amazon Aurora memiliki dua konfigurasi penyimpanan klaster DB:

  • Aurora I/O-Optimized – Peningkatan performa harga dan prediktabilitas untuk aplikasi intensif I/O. Anda hanya membayar penggunaan dan penyimpanan klaster DB Anda, tanpa biaya tambahan untuk operasi I/O baca dan tulis.

    Aurora I/O-Optimized adalah pilihan terbaik ketika pengeluaran I/O Anda adalah 25% atau lebih dari total pengeluaran basis data Aurora Anda.

    Anda dapat memilih Aurora I/O-Optimized saat Anda membuat atau memodifikasi klaster DB dengan versi mesin DB yang mendukung konfigurasi klaster Aurora I/O-Optimized. Anda dapat beralih dari Aurora I/O-Optimized ke Aurora Standard kapan saja.

  • Aurora Standard – Harga hemat biaya untuk banyak aplikasi dengan penggunaan I/O sedang. Selain penggunaan dan penyimpanan klaster DB, Anda juga membayar tarif standar per 1 juta permintaan untuk operasi I/O.

    Aurora Standard adalah pilihan terbaik ketika pengeluaran I/O Anda kurang dari 25% dari total pengeluaran basis data Aurora Anda.

    Anda dapat beralih dari Aurora Standard ke Aurora I/O-Optimized sekali setiap 30 hari. Tidak ada downtime saat Anda beralih dari Aurora Standard keAurora I/O-Optimized, atau dari Aurora I/O-Optimized keAurora Standard.

Untuk informasi tentang Wilayah AWS dan dukungan versi, lihat Daerah yang Didukung dan engine Aurora DB untuk konfigurasi penyimpanan cluster.

Untuk informasi selengkapnya tentang harga konfigurasi penyimpanan Amazon Aurora, lihat Harga Amazon Aurora.

Untuk informasi tentang memilih konfigurasi penyimpanan saat membuat klaster DB, lihat Membuat klaster DB. Untuk informasi tentang memodifikasi konfigurasi penyimpanan untuk klaster DB, lihat Pengaturan untuk Amazon Aurora.

Cara penyimpanan Aurora berubah ukuran secara otomatis

Volume klaster Aurora secara otomatis bertambah seiring peningkatan jumlah data dalam basis data Anda. Ukuran maksimum untuk volume klaster Aurora adalah 128 tebibyte (TiB) atau 64 TiB, bergantung pada versi mesin DB. Untuk detail tentang ukuran maksimum untuk versi tertentu, lihat Batas ukuran Amazon Aurora. Penskalaan penyimpanan otomatis ini dikombinasikan dengan subsistem penyimpanan beperforma tinggi dan sangat terdistribusi. Hal ini menjadikan Aurora sebagai pilihan yang baik untuk data perusahaan Anda yang penting ketika keandalan dan ketersediaan yang tinggi menjadi tujuan utama Anda.

Untuk menampilkan status volume, lihat Menampilkan status volume untuk klaster DB Aurora MySQL atau Menampilkan status volume untuk klaster DB Aurora PostgreSQL. Untuk cara menyeimbangkan biaya penyimpanan dengan prioritas lain, Penskalaan penyimpanan jelaskan cara memantau AuroraVolumeBytesLeftTotal metrik VolumeBytesUsed Amazon Aurora dan masuk. CloudWatch

Saat data Aurora dihapus, ruang yang dialokasikan untuk data tersebut dikosongkan. Contoh penghapusan data termasuk menghapus atau memotong tabel. Pengurangan otomatis penggunaan penyimpanan ini membantu Anda meminimalkan biaya penyimpanan.

catatan

Perilaku pembatasan penyimpanan dan perubahan ukuran dinamis yang dibahas di sini berlaku untuk tabel persisten dan data lain yang disimpan dalam volume klaster.

Untuk Aurora PostgreSQL, data tabel sementara disimpan dalam instans DB lokal.

Untuk Aurora MySQL versi 2, data tabel sementara disimpan secara default dalam volume klaster untuk instans penulis dan dalam penyimpanan lokal untuk instans pembaca. Untuk informasi selengkapnya, lihat Mesin penyimpanan untuk tabel sementara di disk.

Untuk Aurora MySQL versi 3, data tabel sementara disimpan dalam instans DB lokal atau dalam volume klaster. Untuk informasi selengkapnya, lihat Perilaku tabel sementara baru di Aurora MySQL versi 3.

Ukuran maksimum tabel sementara yang berada di penyimpanan lokal dibatasi oleh ukuran penyimpanan lokal maksimum instans DB. Ukuran penyimpanan lokal bergantung pada kelas instans yang Anda gunakan. Lihat informasi yang lebih lengkap di Batas penyimpanan sementara untuk Aurora MySQL dan Batas penyimpanan sementara untuk Aurora PostgreSQL.

Beberapa fitur penyimpanan, seperti ukuran maksimum volume klaster dan pengubahan ukuran otomatis saat data dihapus, bergantung pada versi Aurora klaster Anda. Untuk informasi selengkapnya, lihat Penskalaan penyimpanan. Anda juga dapat mempelajari cara menghindari masalah penyimpanan dan cara memantau penyimpanan yang dialokasikan dan mengosongkan ruang dalam klaster Anda.

Cara penyimpanan data Aurora ditagih

Meskipun volume klaster Aurora dapat bertambah hingga 128 tebibyte (TiB), Anda hanya dikenai biaya untuk ruang yang Anda gunakan dalam volume klaster Aurora. Pada versi Aurora sebelumnya, volume klaster dapat menggunakan kembali ruang yang dikosongkan saat Anda menghapus data, tetapi ruang penyimpanan yang dialokasikan tidak akan pernah berkurang. Saat data Aurora dihapus, seperti menghapus tabel atau basis data, keseluruhan ruang yang dialokasikan berkurang sebesar jumlah yang sebanding. Dengan demikian, Anda dapat mengurangi biaya penyimpanan dengan menghapus tabel, indeks, basis data, dan sebagainya yang tidak lagi Anda butuhkan.

Tip

Untuk versi terdahulu tanpa fitur pengubahan ukuran dinamis, pengaturan ulang penggunaan penyimpanan untuk suatu klaster memerlukan dump logis dan pemulihan ke klaster baru. Operasi tersebut dapat memakan waktu lama untuk volume data yang besar. Jika Anda mengalami situasi ini, pertimbangkan untuk meng-upgrade klaster Anda ke versi yang mendukung pengubahan ukuran volume dinamis.

Untuk informasi tentang versi Aurora yang mendukung pengubahan ukuran dinamis, dan cara meminimalkan biaya penyimpanan dengan memantau penggunaan penyimpanan untuk klaster Anda, lihat Penskalaan penyimpanan. Untuk informasi tentang penagihan penyimpanan cadangan Aurora, lihat Memahami penggunaan penyimpanan cadangan Amazon Aurora. Untuk informasi harga tentang penyimpanan data Aurora, lihat Harga Amazon RDS for Aurora.

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 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. 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 boot ulang dan gagal adalah sebagai berikut:

  • Versi yang lebih lama dari 2.10 – Ketika instans DB penulis melakukan boot ulang, cache halaman pada instans penulis bertahan, tetapi instans DB pembaca kehilangan cache halamannya.

  • Versi 2.10 dan lebih tinggi – Anda dapat melakukan boot ulang instans penulis tanpa melakukan boot ulang instans 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.

Lihat informasi yang lebih lengkap di Toleransi kesalahan untuk klaster DB Aurora dan Optimisasi untuk mengurangi waktu pengaktifan ulang basis data..

Berikut ini adalah pertimbangan untuk logging 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 logging biner yang digunakan memengaruhi ukuran dan efisiensi logging. 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 logging biner, Anda dapat menggunakan binlog yang disempurnakan. Binlog yang disempurnakan mempersingkat waktu pemulihan basis data hingga 99%. Untuk informasi selengkapnya, lihat Menyiapkan binlog yang ditingkatkan.

  • 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 logging 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.