FAQ Amazon Aurora

Amazon Aurora adalah layanan basis data relasional modern yang menawarkan performa dan ketersediaan tinggi dalam skala besar, edisi sumber terbuka penuh yang kompatibel dengan MySQL dan PostgreSQL, serta berbagai alat developer untuk membangun aplikasi berbasis nirserver dan machine learning (ML).

Aurora mengutamakan sistem penyimpanan terdistribusi, toleran terhadap kesalahan, dan dapat melakukan pemulihan mandiri yang dipisahkan dari sumber daya komputasi dan otomatis menaikkan skala hingga 128 TiB per instans basis data. Aurora menghasilkan performa dan ketersediaan tinggi dengan maksimal 15 replika baca latensi rendah, pemulihan titik waktu, pencadangan berkelanjutan ke Amazon Simple Storage Service (Amazon S3), dan replikasi di tiga Zona Ketersediaan (AZ).

Amazon Aurora juga merupakan layanan terkelola penuh yang mengotomatiskan tugas-tugas administrasi yang menghabiskan waktu seperti penyediaan perangkat keras, penyiapan basis data, patching, dan pencadangan sembari menyediakan keamanan, ketersediaan, dan keandalan basis data komersial dengan biaya hanya 1/10 nya.

Amazon Aurora sepenuhnya kompatibel dengan basis data sumber terbuka MySQL yang ada dan menambah dukungan untuk rilis baru secara berkala. Ini berarti Anda dapat dengan mudah memindahkan basis data MySQL ke dan dari Aurora menggunakan snapshot atau alat impor/ekspor standar. Hal ini juga bahwa berarti sebagian besar kode, aplikasi, driver, dan alat yang sudah Anda gunakan saat ini dengan basis data MySQL dapat digunakan bersama Aurora dengan sedikit atau tanpa perubahan. Hal ini memudahkan untuk memindahkan aplikasi antara dua mesin.

Anda dapat melihat informasi terbaru mengenai kompatibilitas perilisan Amazon Aurora MySQL di dokumentasi.

Amazon Aurora sepenuhnya kompatibel dengan basis data sumber terbuka PostgreSQL yang ada dan menambah dukungan untuk perilisan baru secara berkala. Ini berarti Anda dapat secara mudah memigrasikan basis data PostgreSQL ke dan dari Aurora menggunakan snapshot atau alat impor/ekspor standar. Hal ini juga berarti sebagian besar kode, aplikasi, driver, dan alat yang sudah Anda gunakan saat ini dengan basis data PostgreSQL dapat digunakan bersama Aurora dengan sedikit atau tanpa perubahan.

Anda dapat melihat informasi terbaru mengenai kompatibilitas perilisan Amazon Aurora PostgreSQL di dokumentasi.

Amazon secara penuh mendukung Aurora PostgreSQL dan semua ekstensi yang tersedia dengan Aurora. Jika Anda membutuhkan dukungan untuk Aurora PostgreSQL, harap hubungi Dukungan AWS. Jika Anda memiliki akun AWS Premium Support yang aktif, Anda dapat menghubungi AWS Premium Support untuk masalah khusus Amazon Aurora.

Untuk mencoba Amazon Aurora, masuk ke Konsol Manajemen AWS, pilih RDS di bawah kategori Basis Data, lalu pilih Amazon Aurora sebagai mesin basis data Anda. Untuk detail panduan dan sumber daya, baca halaman Getting started with Aurora kamu.

Untuk Aurora yang disediakan, Anda dapat memilih Instans Sesuai Permintaan dan membayar basis data Anda per jam tanpa komitmen jangka panjang atau biaya di muka, atau memilih Instans Cadangan untuk penghematan tambahan. Atau, Aurora Nirserver secara otomatis memulai, mematikan, dan meningkatkan atau menurunkan skala kapasitas berdasarkan kebutuhan aplikasi Anda dan Anda hanya membayar untuk kapasitas yang digunakan.

Harap baca halaman harga Aurora kami untuk informasi harga saat ini.

Tidak. Replikasi Amazon Aurora sudah termasuk dalam harga tersebut. Anda akan dikenai biaya berdasarkan penyimpanan yang basis data Anda gunakan pada lapisan basis data, bukan penyimpanan yang digunakan dalam lapisan penyimpanan virtual Amazon Aurora.

Anda dapat melihat ketersediaan wilayah untuk Amazon Aurora di sini.

Jika Anda ingin memigrasikan dari MySQL ke Amazon Aurora (dan sebaliknya), Anda mempunyai beberapa opsi:

• Anda dapat menggunakan utilitas mysqldump standar untuk mengekspor data dari MySQL dan utilitas mysqlimport untuk mengimpor data ke Amazon Aurora, begitu pula sebaliknya.
• Anda juga dapat menggunakan fitur migrasi Snapshot DB Amazon RDS untuk memigrasikan Snapshot DB Amazon RDS for MySQL ke Amazon Aurora menggunakan Konsol Manajemen AWS.

Migrasi ke Aurora untuk sebagian besar pelanggan biasanya selesai dalam waktu kurang dari satu jam, meski durasi tersebut bergantung pada format dan ukuran set data. Untuk informasi selengkapnya, lihat Praktik terbaik untuk Melakukan Migrasi basis data MySQL ke Amazon Aurora.

Jika Anda ingin memigrasikan dari PostgreSQL ke Amazon Aurora (dan sebaliknya), Anda mempunyai beberapa opsi:

• Anda dapat menggunakan utilitas pg_dump standar untuk mengekspor data dari PostgreSQL dan utilitas pg_restore untuk mengimpor data ke Amazon Aurora, begitu pula sebaliknya.
• Anda juga dapat menggunakan fitur migrasi Snapshot DB Amazon RDS untuk memigrasikan Snapshot DB Amazon RDS for PostgreSQL ke Amazon Aurora menggunakan Konsol Manajemen AWS.

Migrasi ke Aurora untuk sebagian besar pelanggan biasanya selesai dalam waktu kurang dari satu jam, meski durasi tersebut bergantung pada format dan ukuran set data.

Untuk memigrasikan basis data SQL Server ke Aurora Edisi Kompatibel PostgreSQL, Anda dapat menggunakan Babelfish untuk Aurora PostgreSQL. Aplikasi Anda akan berfungsi tanpa ada perubahan. Lihat dokumentasi Babelfish untuk informasi selengkapnya.

Tidak untuk saat ini. AWS Tingkat Gratis untuk Amazon RDS menawarkan keuntungan untuk Instans Micro DB; Amazon Aurora saat ini tidak memberikan dukungan Instans Micro DB. Harap baca halaman harga Aurora untuk informasi harga saat ini.
Untuk mencoba Amazon Aurora, masuk ke Konsol Manajemen AWS, pilih RDS di bawah kategori Basis Data, lalu pilih Amazon Aurora sebagai mesin basis data Anda.

I/O adalah operasi input/output yang dilakukan mesin basis data Aurora pada lapisan penyimpanan virtual berbasis solid state drive (SSD) miliknya. Setiap operasi baca halaman basis data dihitung sebagai satu I/O.

Mesin basis data Aurora mengeluarkan pembacaan pada lapisan penyimpanan untuk mengambil halaman basis data yang tidak tersedia di memori dalam cache:

• Jika lalu lintas kueri Anda dapat dilayani sepenuhnya dari memori atau cache, Anda tidak akan ditagih biaya untuk mengambil halaman data apa pun dari memori.
• Jika lalu lintas kueri Anda tidak dapat dilayani sepenuhnya dari memori, Anda akan ditagih biaya untuk halaman data apa pun yang perlu diambil dari penyimpanan.

Setiap halaman basis data berukuran 16 KB dalam Aurora Edisi Kompatibel MySQL dan 8 KB dalam Aurora Edisi Kompatibel PostgreSQL.

Aurora didesain untuk menghapus operasi I/O yang tidak diperlukan guna mengurangi biaya serta memastikan sumber daya tersedia untuk melakukan lalu lintas baca/tulis. I/O tulis hanya digunakan ketika mempertahankan catatan log pengulangan di Aurora Edisi Kompatibel MySQL atau menulis di depan catatan log di Aurora Edisi Kompatibel PostgreSQL ke lapisan penyimpanan yang bertujuan agar penulisan bertahan lama.

I/O tulis dihitung dalam unit 4 KB. Contohnya, catatan log yang berukuran 1024 bytes akan dihitung sebagai satu operasi I/O tulis. Namun, jika catatan log lebih besar dari 4 KB, lebih dari satu operasi I/O tulis akan diperlukan untuk mempertahankannya.

Operasi tulis bersamaan yang catatan log-nya kurang dari 4 KB dapat di-batch bersama dengan mesin basis data Aurora untuk mengoptimalkan konsumsi I/O, jika dipertahanakan di grup perlindungan penyimpanan yang sama. Tidak seperti mesin basis data tradisional, Aurora tidak pernah mendorong halaman data kotor ke penyimpanan.

Anda dapat melihat berapa banyak permintaan I/O yang digunakan instans Aurora Anda dengan membuka Konsol Manajemen AWS. Untuk mencari tahu penggunaan I/O Anda, buka bagian Amazon RDS pada konsol, lihat daftar instans Anda, pilih instans Aurora, lalu cari metrik “Operasi baca tertagih” dan “Operasi tulis tertagih” di bagian pemantauan.

Tidak perlu, Amazon Aurora akan bekerja dengan driver basis data PostgreSQL standar.

Amazon Aurora menghasilkan peningkatan yang signifikan atas performa MySQL melalui integrasi mesin basis data dengan lapisan penyimpanan virtual berbasis SSD yang dibuat khusus untuk beban kerja basis data, mengurangi penulisan pada sistem penyimpanan, meminimalkan ketidaksesuaian, dan mengurangi penundaan yang dibuat oleh utas proses basis data.

Tes kami dengan SysBench pada instans r3.8xlarge menunjukkan bahwa Amazon Aurora mengirimkan 500.000 SELECT/detik dan 100.000 UPDATE/detik, lima kali lipat lebih tinggi dari MySQL yang berjalan pada benchmark yang sama dan pada perangkat keras yang sama. Petunjuk detail tentang tolok ukur ini dan cara untuk mereplikasinya sendiri tersedia dalam Panduan Tolok Ukur Performa MySQL Amazon Aurora.

Amazon Aurora menghasilkan peningkatan yang signifikan atas kinerja PostgreSQL melalui integrasi mesin basis data dengan lapisan penyimpanan virtual berbasis SSD yang dibuat khusus untuk beban kerja basis data, mengurangi penulisan pada sistem penyimpanan, meminimalkan ketidaksesuaian, dan mengurangi penundaan yang dibuat utas proses basis data.

Tes kami dengan SysBench pada instans r4.16xlarge menunjukkan bahwa Amazon Aurora mengirimkan SELECT/detik dan UPDATE/detik tiga kali lipat lebih tinggi dari PostgreSQL yang berjalan pada benchmark yang sama dan pada perangkat keras yang sama. Petunjuk terperinci tentang tolok ukur ini dan cara untuk mereplikasinya sendiri tersedia dalam Panduan Tolok Ukur Kinerja Amazon Aurora Edisi Kompatibel PostgreSQL.

Amazon Aurora dirancang agar kompatibel dengan MySQL, sehingga aplikasi dan alat MySQL yang ada dapat berjalan tanpa perlu dimodifikasi. Namun, satu area tempat Amazon Aurora mengalami peningkatan dibandingkan MySQL adalah area dengan beban kerja yang sangat konkuren. Untuk memaksimalkan throughput beban kerja Anda pada Amazon Aurora, kami menyarankan untuk membangun aplikasi Anda guna mendorong kueri dan transaksi bersamaan dalam jumlah besar.

Amazon Aurora didesain agar kompatibel dengan PostgreSQL, sehingga aplikasi dan alat PostgreSQL yang ada dapat berjalan tanpa memerlukan modifikasi. Namun, satu area tempat Amazon Aurora meningkatkan PostgreSQL adalah area dengan beban kerja yang sangat konkuren. Untuk memaksimalkan throughput beban kerja Anda pada Amazon Aurora, kami merekomendasikan untuk membangun aplikasi Anda guna mendorong kueri dan transaksi konkuren dalam jumlah besar.

Penyimpanan minimum adalah 10 GB. Berdasarkan penggunaan basis data Anda, penyimpanan Amazon Aurora akan otomatis berkembang, hingga 128 TiB, dalam peningkatan 10 GB tanpa memengaruhi performa basis data. Tidak perlu menyediakan penyimpanan terlebih dahulu.

Ada dua cara untuk menskalakan sumber daya komputasi yang terkait dengan Instans DB Amazon Aurora saya – melalui Aurora Nirserver dan melalui penyesuaian manual.

Anda dapat menggunakan Aurora Nirserver, sebuah konfigurasi penskalaan otomatis sesuai permintaan untuk Amazon Aurora guna menskalakan sumber daya komputasi basis data berdasarkan permintaan aplikasi. Dengan Aurora Nirserver, Anda dapat menjalankan basis data di cloud tanpa perlu mengkhawatirkan manajemen kapasitas basis data. Anda dapat menentukan rentang kapasitas basis data yang Anda inginkan dan basis data akan diskalakan berdasarkan kebutuhan aplikasi Anda. Baca selengkapnya di Panduan Pengguna Aurora Nirserver.

Anda juga dapat secara manual menskalakan sumber daya komputasi yang terkait dengan basis data dengan memilih tipe instans DB yang Anda inginkan di Konsol Manajemen AWS. Perubahan yang Anda minta akan diterapkan selama periode pemeliharaan yang Anda tentukan atau Anda dapat menggunakan bendera “Terapkan Segera” untuk segera mengubah tipe instans DB.

Kedua opsi ini akan memiliki pengaruh ketersediaan selama beberapa menit saat operasi penskalaan dijalankan. Ingat bahwa perubahan sistem yang tertunda lainnya juga akan diterapkan.

Pencadangan berkelanjutan yang otomatis selalu diaktifkan pada Instans DB Amazon Aurora. Pencadangan tidak memengaruhi kinerja basis data.

Ya, dan tidak akan ada pengaruh pada kinerja saat mengambil snapshot. Perhatikan bahwa pemulihan data dari Snapshot DB memerlukan pembuatan Instans DB yang baru.

Amazon Aurora secara otomatis mempertahankan enam salinan data di tiga Zona Ketersediaan (AZ) dan secara otomatis mencoba untuk memulihkan basis data Anda di AZ yang sehat tanpa kehilangan data. Seandainya data Anda tidak tersedia dalam penyimpanan Amazon Aurora, Anda dapat melakukan pemulihan dari Snapshot DB atau melakukan operasi pemulihan waktu tertentu pada instans yang baru. Perhatikan bahwa waktu terakhir yang dapat dipulihkan untuk operasi pemulihan waktu tertentu adalah hingga lima menit yang lalu.

Anda dapat memilih untuk membuat Snapshot DB akhir saat menghapus Instans DB Anda. Jika melakukannya, Anda dapat menggunakan Snapshot DB untuk memulihkan Instans DB yang dihapus di kemudian hari. Amazon Aurora mempertahankan Snapshot DB yang dibuat pengguna terakhir ini bersama dengan semua Snapshot DB yang dibuat secara manual setelah Instans DB dihapus. Hanya Snapshot DB yang dipertahankan setelah Instans DB dihapus (artinya, pencadangan otomatis yang dibuat untuk pemulihan waktu tertentu tidak disimpan).

Ya. Aurora memberikan Anda kemampuan untuk membuat snapshot database Anda, yang dapat Anda gunakan nanti untuk memulihkan database. Anda dapat membagikan snapshot dengan akun AWS berbeda, lalu pemilik akun penerima dapat menggunakan snapshot Anda untuk memulihkan DB yang memuat data Anda. Anda bahkan dapat memilih untuk membuat snapshot Anda menjadi publik – artinya, siapa pun dapat memulihkan DB yang memuat data (publik) Anda.

Anda dapat menggunakan fitur ini untuk berbagi data di antara berbagai lingkungan (produksi, dev/tes, uji coba, dll.) yang memiliki akun AWS berbeda-beda, dan juga menjaga cadangan data Anda tetap aman di akun terpisah jika akun AWS utama Anda telah disusupi.

Tidak ada biaya untuk berbagi snapshot antarakun. Namun, Anda mungkin dikenakan biaya atas snapshot itu sendiri, dan juga basis data apa pun yang Anda pulihkan dari snapshot yang dibagikan. Pelajari selengkapnya mengenai harga Aurora.

Kami tidak mendukung pembagian snapshot DB otomatis. Untuk membagikan snapshot, Anda harus membuat salinan snapshot secara manual, lalu membagikan salinan tersebut.

Anda dapat membagikan snapshot manual dengan hingga 20 ID akun AWS. Jika Anda ingin membagikan snapshot dengan lebih dari 20 akun, Anda dapat membagikan snapshot sebagai publik, atau menghubungi pusat bantuan untuk meningkatkan kuota Anda.

Anda dapat membagikan snapshot Aurora di semua wilayah AWS tempat Aurora tersedia.

Tidak. Snapshot Aurora yang Anda bagikan hanya dapat diakses oleh akun yang berada di wilayah yang sama dengan akun yang membagikannya.

Ya, Anda dapat membagikan snapshot Aurora yang dienkripsi.

Amazon Aurora secara otomatis membagi volume basis data Anda ke dalam segmen-segmen berukuran 10 GB yang tersebar di banyak disk. Setiap 10 GB bagian volume basis data Anda direplikasi dengan enam cara di tiga Zona Ketersediaan. Amazon Aurora dirancang untuk secara transparan menangani kehilangan maksimal dua salinan data tanpa memengaruhi ketersediaan penulisan basis data dan maksimal tiga salinan tanpa memengaruhi ketersediaan pembacaan.

Penyimpanan Amazon Aurora juga dapat pulih dengan sendirinya. Blok data dan disk terus dipindai untuk mencari kesalahan dan akan otomatis diperbaiki.

Tidak seperti basis data lain, setelah basis data macet, Amazon Aurora tidak perlu memutar ulang log pengulangan dari titik pemeriksaan basis data terakhir (biasanya lima menit) dan mengonfirmasi bahwa semua telah diterapkan sebelum menyediakan basis data untuk operasi. Hal ini mengurangi waktu restart basis data hingga menjadi kurang dari 60 detik di sebagian besar kasus.

Amazon Aurora memindahkan cache buffer keluar dari proses database dan menjadikannya tersedia segera pada waktu restart. Dengan demikian, Anda tidak perlu membatasi akses hingga cache diisi kembali untuk menghindari ketidaktersediaan.

Amazon Aurora Edisi Kompatibel MySQL dan Amazon Aurora Edisi Kompatibel PostgreSQL mendukung replika Amazon Aurora, yang memiliki volume dasar sama dengan instans primer di wilayah AWS yang sama. Pembaruan yang dibuat oleh primer terlihat pada semua Replika Amazon Aurora.

Dengan Amazon Aurora Edisi Kompatibel MySQL, Anda juga dapat membuat Replika Baca MySQL antarwilayah berdasarkan mesin replikasi berbasis binlog MySQL. Di Replika Baca MySQL, data dari instans primer Anda akan diputar kembali pada replika Anda sebagai transaksi. Untuk sebagian besar kasus penggunaan, termasuk penskalaan baca dan ketersediaan yang sangat baik, kami menyarankan penggunaan Replika Amazon Aurora.

Anda memiliki fleksibilitas untuk memadupadankan kedua jenis replika ini berdasarkan keperluan aplikasi Anda:

Anda memiliki dua opsi replikasi tambahan selain opsi yang tercantum di atas. Anda dapat menggunakan Basis Data Global Amazon untuk replikasi fisik yang jauh lebih cepat antara klaster Aurora dalam wilayah yang berbeda. Untuk replikasi antara basis data Aurora dan selain Aurora Edisi Kompatibel MySQL (bahkan di luar AWS), Anda dapat menyiapkan replikasi binlog milik Anda yang dikelola sendiri.

Ya, Anda dapat menyiapkan replika Aurora lintas wilayah menggunakan replikasi logika atau fisik. Replikasi fisik, yang disebut Amazon Aurora Global Database, menggunakan infrastruktur khusus yang membuat basis data Anda tersedia sepenuhnya untuk menyokong aplikasi, dan dapat mereplikasi hingga lima wilayah sekunder dengan latensi umum di bawah satu detik. Replika ini tersedia untuk Aurora Edisi Kompatibel MySQL maupun Aurora Edisi Kompatibel PostgreSQL.

Untuk pembacaan global latensi rendah dan pemulihan bencana, kami sarankan untuk menggunakan Amazon Aurora Global Database.
Aurora mendukung replikasi logika native di tiap mesin basis data (binlog untuk MySQL dan slot replika PostgreSQL untuk PostgreSQL), jadi Anda bisa mereplikasi ke basis data Aurora dan non-Aurora, bahkan lintas wilayah.

Aurora Edisi Kompatibel MySQL juga menawarkan fitur replika baca lintas wilayah logika mudah pakai yang mendukung hingga lima wilayah AWS sekunder. Aurora Edisi Kompatibel MySQL didasarkan pada replikasi binlog MySQL berutas tunggal, sehingga ketertinggalan replikasi akan dipengaruhi tingkat perubahan/pengaplikasian serta penundaan dalam komunikasi jaringan antarwilayah khusus yang dipilih.

Ya, Anda dapat menambahkan hingga 15 Replika Aurora pada tiap klaster lintas wilayah, dan replika tersebut akan memiliki penyimpanan dasar yang sama seperti replika lintas wilayah. Replika lintas wilayah bertindak sebagai primer pada klaster dan Replika Aurora pada klaster biasanya akan tertinggal sepuluh milidetik di belakang primer.

Ya, Anda dapat mempromosikan replika lintas wilayah menjadi primer baru dari konsol Amazon RDS. Untuk replikasi logika (binlog), proses promosi biasanya membutuhkan waktu beberapa menit, tergantung pada beban kerja Anda. Replikasi lintas wilayah akan berhenti setelah Anda menjalankan proses promosi.

Dengan Basis Data Global Amazon Aurora, Anda dapat mempromosikan wilayah sekunder untuk mengambil beban kerja baca/tulis penuh dalam waktu kurang dari satu menit.

Ya. Anda dapat menetapkan tingkat prioritas promosi untuk setiap instans pada klaster Anda. Saat instans primer gagal, Amazon RDS akan mempromosikan replika dengan prioritas tertinggi menjadi primer. Jika dua atau lebih Replika Aurora berbagi prioritas yang sama, maka Amazon RDS akan mempromosikan replika dengan ukuran paling besar. Jika dua atau lebih Replika Aurora berbagi prioritas dan ukuran yang sama, maka Amazon RDS akan mempromosikan replika arbitrer dengan tingkat promosi yang sama.

Untuk informasi selengkapnya mengenai logika failover, baca Panduan Pengguna Amazon Aurora.

Ya, Anda dapat mengubah tingkat prioritas untuk instans kapan pun. Mengubah tingkat prioritas tidak akan memicu failover.

Anda dapat menetapkan tingkat prioritas yang lebih rendah pada replika yang tidak ingin Anda promosikan menjadi instans primer. Namun, jika replika dengan prioritas lebih tinggi pada klaster tidak sehat atau tidak tersedia karena alasan tertentu, maka Amazon RDS akan mempromosikan replika dengan prioritas yang lebih rendah tersebut.

Anda dapat menambahkan Replika Amazon Aurora. Replika Aurora di Wilayah AWS yang sama memliki penyimpanan mendasar yang sama seperti instans primer. Setiap Replika Aurora dapat dipromosikan menjadi primer tanpa perlu kehilangan data, dan oleh karena itu dapat digunakan untuk meningkatkan toleransi kesalahan saat terjadi kegagalan Instans DB primer.

Untuk meningkatkan ketersediaan basis data, cukup buat 15 replika, di salah satu dari tiga AZ, lalu Amazon RDS akan otomatis menyertakan mereka dalam pilihan primer failover saat sebuah basis data mati. Anda dapat menggunakan Amazon Aurora Global Database jika ingin basis data menjangkau beberapa Wilayah AWS. Tindakan ini akan mereplikasi data Anda tanpa memengaruhi performa basis data dan memberikan pemulihan bencana dari pemadaman dalam lingkup wilayah.

Failover secara otomatis ditangani oleh Amazon Aurora sehingga aplikasi Anda dapat melanjutkan operasi basis data sesegera mungkin tanpa intervensi administratif manual.

• Jika Anda memiliki Replika Amazon Aurora, dalam Zona Ketersediaan yang sama atau berbeda, saat terjadi failover, Aurora akan membalikkan catatan nama kanonik (CNAME) bagi Instans DB Anda untuk menunjukkan replika yang sehat, yang pada akhirnya akan dipromosikan untuk menjadi primer baru. Dari awal hingga selesai, failover biasanya selesai dalam 30 detik. 
• Jika Anda menjalankan Aurora Nirserver dan instans DB atau AZ menjadi tidak tersedia, Aurora akan secara otomatis membuat ulang instans DB dalam AZ berbeda. 
• Jika Anda tidak memiliki Replika Amazon Aurora (yaitu satu instans) dan tidak sedang menjalankan Aurora Nirserver, Aurora akan mencoba untuk membuat Instans DB baru dalam Availability Zone yang sama dengan instans asli. Penggantian instans asli dilakukan berdasarkan usaha terbaik dan memiliki kemungkinan tidak berhasil, sebagai contoh, jika terjadi masalah yang memengaruhi Availability Zone secara luas.
  

Aplikasi Anda harus mencoba ulang koneksi database jika terjadi kehilangan koneksi. Pemulihan bencana di seluruh wilayah adalah proses manual, saat Anda mempromosikan wilayah sekunder untuk mengambil beban kerja baca/tulis.

Amazon Aurora akan secara otomatis mendeteksi masalah dengan instans utama Anda dan memicu failover. Jika Anda menggunakan Titik Akhir Klaster, koneksi baca/tulis akan secara otomatis diarahkan ulang ke Replika Amazon Aurora yang akan dipromosikan ke utama.

Selain itu, lalu lintas baca yang disediakan Replika Aurora Anda akan terputus sebentar. Jika Anda menggunakan Titik Akhir Pembaca Klaster untuk mengarahkan lalu lintas baca ke Replika Aurora, koneksi hanya baca akan diarahkan ke Replika Aurora yang baru dipromosikan hingga simpul primer lama dipulihkan sebagai replika.

Karena Replika Amazon Aurora memiliki volume data yang sama dengan instans primer di Wilayah AWS yang sama, ketertinggalan replikasi hampir tidak ada. Kami biasanya mengamati waktu ketertinggalan dalam sepuluh milidetik.

Untuk replika lintas wilayah, ketertinggalan replikasi logika berbasis binlog bisa meningkat tidak menentu berdasarkan tingkat perubahan/penerapan dan juga penundaan dalam komunikasi jaringan. Namun, dalam kondisi umum, ketertinggalan replikasi di bawah satu menit adalah hal yang biasa. Replika antarwilayah yang menggunakan replikasi fisik Basis Data Global Amazon Aurora akan memiliki ketertinggalan normal kurang dari satu detik.

Ya, Anda dapat mengatur replikasi binlog antara instans Aurora Edisi yang Kompatibel dengan MySQL dan basis data MySQL eksternal. Basis data yang lain dapat berjalan pada Amazon RDS, atau sebagai basis data terkelola mandiri di AWS, atau sepenuhnya di luar AWS.

Jika Anda menjalankan Aurora Edisi yang Kompatibel dengan MySQL 5.7, pertimbangkan untuk menyiapkan replikasi binlog berbasis GTID. Hal ini akan memberikan konsistensi penuh sehingga replika Anda tidak akan melewatkan transaksi atau menghasilkan konfilk, bahkan setelah terjadi failover atau waktu henti.

Basis Data Global Amazon Aurora adalah fitur yang memungkinkan satu basis data Amazon Aurora untuk menjangkau beberapa wilayah AWS. Fitur ini mereplikasi data Anda tanpa berpengaruh pada kinerja basis data, memungkinkan pembacaan lokal yang cepat di setiap wilayah dengan latensi umumnya kurang dari satu detik, dan menyediakan pemulihan bencana dari pemadaman dalam lingkup wilayah. Jika terjadi degradasi atau pemadaman tingkat wilayah, wilayah sekunder dapat dipromosikan ke kemampuan baca/tulis penuh dalam waktu kurang dari satu menit. Fitur ini tersedia untuk Aurora Edisi Kompatibel MySQL maupun Aurora Edisi Kompatibel PostgreSQL.

Anda dapat membuat Aurora Global Database hanya dengan beberapa klik di Konsol Amazon RDS. Atau, Anda dapat menggunakan Kit Pengembangan Perangkat Lunak (SDK) AWS atau Antarmuka Baris Perintah (CLI) AWS. Anda perlu menyediakan setidaknya satu instans per wilayah di Basis Data Global Amazon Aurora Anda.

Anda dapat membuat hingga lima wilayah sekunder untuk Basis Data Global Amazon Aurora.

Ya. Jika tujuan Anda adalah untuk menganalisis aktivitas basis data, pertimbangkan untuk menggunakan audit lanjutan Aurora, log umum, dan log kueri lambat sebagai gantinya agar performa basis data tidak terpengaruh.

Tidak. Jika wilayah primer menjadi tidak tersedia, Anda dapat menghapus wilayah sekunder secara manual dari Basis Data Global Amazon Aurora dan mempromosikannya untuk melakukan pembacaan dan penulisan penuh. Anda juga perlu mengarahkan aplikasi ke wilayah baru yang dipromosikan.

Amazon Aurora Multimaster adalah fitur baru Aurora Edisi yang Kompatibel dengan MySQL yang menambahkan kemampuan untuk menskalakan ke luar performa tulis di beberapa Zona Ketersediaan, memungkinkan aplikasi mengarahkan beban kerja baca/tulis ke beberapa instans di klaster basis data, dan beroperasi dengan ketersediaan yang lebih baik.

Amazon Aurora Multimaster kini tersedia untuk umum. Anda dapat membaca dokumentasi Amazon Aurora untuk mempelajari selengkapnya. Anda dapat membuat klaster Aurora Multimaster hanya dengan beberapa klik di konsol Amazon RDS atau mengunduh SDK atau CLI AWS terbaru.

Ya, semua Instans DB Amazon Aurora harus dibuat di dalam VPC. Dengan Amazon VPC, Anda dapat menentukan topologi jaringan virtual yang mirip dengan jaringan tradisional yang mungkin Anda operasikan di pusat data Anda sendiri. Hal ini memberikan Anda kontrol penuh atas siapa yang dapat mengakses basis data Amazon Aurora Anda.

Ya. Amazon Aurora menggunakan SSL (AES-256) untuk mengamankan koneksi antara instans basis data dan aplikasi. Amazon Aurora memungkinkan Anda mengenkripsi basis data menggunakan kunci yang Anda kelola melalui AWS Key Management Service (AWS KMS).

Pada instans basis data yang berjalan dengan enkripsi Amazon Aurora, data yang disimpan saat diam di penyimpanan dasar dienkripsi, begitu juga cadangan otomatis, snapshot, dan replika dalam klaster yang sama. Enkripsi dan dekripsi ditangani dengan mulus. Untuk informasi selengkapnya mengenai penggunaan AWS KMS dengan Amazon Aurora, lihat Panduan Pengguna Amazon RDS.

Saat ini, enkripsi instans Aurora yamg tidak terenkripsi yang sudah ada belum didukung. Untuk menggunakan enkripsi Amazon Aurora untuk basis data yang tidak terenkripsi, buat Instans DB baru dengan enkripsi aktif lalu migrasikan data Anda ke instans tersebut.

Akses ke basis data Amazon Aurora harus dilakukan melalui port basis data yang dimasukkan saat pembuatan basis data. Hal ini memberikan lapisan keamanan tambahan untuk data Anda. Petunjuk langkah demi langkah mengenai cara menyambungkan ke basis data Amazon Aurora Anda tersedia dalam Panduan Konektivitas Amazon Aurora.

Ya, Aurora edisi kompatibel PostgreSQL dan MySQL memenuhi syarat Undang-undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (HIPAA), sehingga Anda dapat menggunakannya untuk membangun aplikasi yang mematuhi HIPAA dan menyimpan informasi yang berhubungan dengan layanan kesehatan, termasuk informasi kesehatan yang dilindungi (PHI) berdasarkan Perjanjian Rekan Bisnis (BAA) yang dijalankan dengan AWS. Jika Anda memiliki BAA yang telah dijalankan, tidak ada tindakan yang perlu dilakukan untuk mulai menggunakan layanan ini di akun yang dicakup oleh BAA Anda. Untuk informasi selengkapnya tentang membangun aplikasi yang memenuhi syarat di AWS, lihat Penyedia & Penjamin Layanan Kesehatan di Cloud.

Saat ini Anda dapat menemukan daftar di Pembaruan Keamanan Amazon Aurora.

Aurora Nirserver merupakan konfigurasi penskalaan otomatis sesuai permintaan untuk Amazon Aurora. Dengan Amazon Aurora Nirserver, Anda dapat menjalankan basis data di cloud tanpa perlu mengelola kapasitas basis data. Mengelola kapasitas basis data secara manual dapat memakan waktu dan dapat berujung pada penggunaan sumber daya basis data yang tidak efisien. Dengan Aurora Nirserver, Anda cukup membuat basis data, menentukan rentang kapasitas basis data yang diinginkan, dan menghubungkan aplikasi Anda. Aurora akan secara otomatis menyesuaikan kapasitas di dalam rentang yang telah Anda tentukan berdasarkan kebutuhan aplikasi Anda.

Anda akan membayar kapasitas basis data yang Anda gunakan dengan basis per detik saat basis data aktif. Pelajari selengkapnya mengenai Aurora Nirserver dan mulai hanya dengan beberapa klik di Konsol Manajemen Amazon RDS.

Aurora Nirserver v2 mendukung setiap jenis beban kerja basis data, mulai dari lingkungan pengembangan dan pengujian, situs web, serta aplikasi yang memiliki beban kerja yang jarang, sesekali, atau tidak terduga hingga aplikasi yang paling membutuhkan perhatian dan penting untuk bisnis, yang memerlukan penskalaan dan ketersediaan tinggi. Aurora Nirserver v2 akan menskalakan ke dalam saat itu juga dengan menambahkan lebih banyak CPU dan memori tanpa harus melakukan failover basis data ke instans basis data yang lebih besar atau lebih kecil. Sebagai hasilnya, Aurora Nirserver v2 akan dapat menskalakan meskipun terdapat transaksi yang berjalan lama, tabel terkunci, dan hal lainnya.

Selain itu, Aurora Nirserver v2 menskalakan kapasitas basis data dengan penambahan hanya 0,5 Unit Kapasitas Aurora (ACU) sehingga kapasitas basis data akan sangat sesuai dengan kebutuhan aplikasi Anda.

Aurora Nirserver v1 merupakan opsi yang sederhana dan hemat biaya untuk beban kerja yang jarang, sesekali, atau tidak terduga. Aurora Nirserver v1 secara otomatis akan memulai, menskalakan kapasitas komputasi agar sesuai dengan penggunaan aplikasi Anda, dan mati saat tidak digunakan. Kunjungi Panduan Pengguna Aurora untuk mempelajari selengkapnya.

Aurora Nirserver v2 mendukung semua fitur Aurora yang disediakan, termasuk replika baca, konfigurasi multi-AZ, Basis Data Global, proxy RDS, dan Wawasan Performa.

Ya, Anda dapat mulai menggunakan Aurora Nirserver v2 untuk mengelola kapasitas komputasi basis data di klaster DB Aurora yang sudah ada. Klaster yang memiliki instans yang disediakan dan Aurora Nirserver v2 disebut sebagai klaster konfigurasi campuran. Anda dapat memilih setiap kombinasi instans yang disediakan dan Aurora Nirserver v2 di klaster Anda.

Untuk menguji Aurora Nirserver v2, Anda dapat menambahkan pembaca ke klaster DB Aurora dan memilih Nirserver v2 sebagai tipe instans. Setelah pembaca dibuat dan tersedia, Anda dapat mulai menggunakannya untuk beban kerja mode baca saja. Setelah Anda mengonfirmasi bahwa pembaca bekerja sebagaimana mestinya, Anda dapat menginisiasi failover untuk mulai menggunakan Aurora Nirserver v2 baik untuk tulis maupun baca. Opsi ini menyediakan pengalaman waktu henti minimal untuk mulai menggunakan Aurora Nirserver v2.

Ya, Anda dapat bermigrasi dari Aurora Nirserver v1 ke Aurora Nirserver v2. Baca Panduan Pengguna Aurora untuk mempelajari selengkapnya.

Informasi kompatibilitas Aurora Nirserver v1 dapat dilihat di sini. Informasi kompatibilitas Aurora Nirserver v2 dapat dilihat di sini.

Ya, Anda dapat memulihkan snapshot yang diambil dari klaster yang disediakan Aurora yang sudah ada ke Klaster DB Aurora Nirserver (dan sebaliknya).

Anda dapat mengakses klaster DB Aurora Nirserver dari dalam aplikasi klien yang berjalan dalam VPC yang sama. Anda tidak dapat memberikan alamat IP publik kepada DB Aurora Nirserver.

Sementara Aurora Nirserver melakukan penskalaan secara otomatis berdasarkan beban kerja basis data yang aktif, dalam beberapa kasus, kapasitas mungkin tidak diskalakan cukup cepat untuk memenuhi perubahan beban kerja mendadak, seperti transaksi baru dalam jumlah besar. Dalam kasus ini, Anda dapat mengatur kapasitas secara eksplisit hingga nilai tertentu dengan Konsol Manajemen AWS, AWS CLI, atau API Amazon RDS.

Setelah operasi penskalaan dimulai, Aurora Nirserver mencoba untuk menemukan titik penskalaan, yang merupakan titik tempat basis data dapat diskalakan penuh dengan aman. Aurora Nirserver mungkin tidak dapat menemukan titik penskalaan jika kueri atau transaksi yang berjalan lama sedang dalam progres, atau tabel sementara atau kunci tabel sedang digunakan.

Dalam Aurora Nirserver, kapasitas basis data diukur dalam Unit Kapasitas Aurora (ACU). Anda akan membayar tarif tetap atas penggunaan ACU per detik. Harga penyimpanan dan I/O sama untuk konfigurasi yang disediakan dan nirserver. Kunjungi halaman harga Aurora untuk informasi terbaru mengenai harga dan ketersediaan Wilayah AWS.

Amazon Aurora Parallel Query merujuk pada kemampuan untuk menekan dan mendistribusikan beban komputasi dari satu kueri di ribuan CPU dalam lapisan penyimpanan Aurora. Tanpa Parallel Query, kueri yang dikeluarkan pada basis data Amazon Aurora akan dieksekusi sepenuhnya dalam satu instans klaster basis data; hal ini mirip dengan cara beroperasi dari sebagian besar basis data.

Parallel Query sangat cocok untuk beban kerja yang memerlukan data segar dan performa kueri yang bagus, bahkan pada tabel besar. Beban kerja tipe ini sering kali bersifat operasional.

Parallel Query menghasilkan performa lebih cepat, meningkatkan kecepatan kueri analitik hingga dua urutan magnitudo. Parallel Query juga memberikan kesederhanaan operasional dan kesegaran data karena Anda dapat mengeluarkan kueri secara langsung melalui data transaksional saat ini dalam klaster Aurora Anda. Selain itu, Parallel Query memungkinkan beban kerja transaksional dan analitik pada basis data yang sama dengan memungkinkan Aurora untuk menjaga throughput transaksi tinggi bersama dengan kueri analitik konkuren.

Sebagian besar kueri atas set data besar yang belum ada dalam kumpulan buffer mungkin dapat memperoleh manfaat. Versi awal Parallel Query dapat menekan dan menskalakan ke luar pemrosesan lebih dari 200 fungsi, equijoin, dan proyeksi SQL.

Peningkatkan performa kueri tertentu bergantung pada seberapa banyak rencana kueri yang dapat ditekan ke lapisan penyimpanan Aurora. Pelanggan telah melaporkan bahwa ada lebih dari satu urutan peningkatan magnitudo pada latensi kueri.

Ya, tetapi kami memperkirakan kasus tersebut jarang terjadi.

Perubahan dalam sintaksis kueri tidak diperlukan. Pengoptimal kueri akan otomatis menentukan apakah Parallel Query akan digunakan pada kueri tertentu Anda. Untuk memeriksa apakah sebuah kueri menggunakan Parallel Query, Anda dapat melihat rencana eksekusi kueri dengan menjalankan perintah EXPLAIN. Jika Anda ingin melewati heuristik dan mendorong Parallel Query untuk tujuan pengujian, gunakan variabel sesi aurora_pq_force.

Parallel Query dapat diaktifkan dan dinonaktifkan secara dinamis pada tingkat global dan sesi menggunakan parameter aurora_pq.

Tidak. Anda tidak dikenakan biaya apa pun selain yang sudah Anda bayar untuk instans, I/O, dan penyimpanan.

Tidak. Biaya I/O Parallel Query untuk kueri Anda diukur pada lapisan penyimpanan dan akan tetap sama atau lebih besar jika Parallel Query diaktifkan. Manfaat yang Anda dapatkan adalah peningkatan performa kueri.

Terdapat dua alasan untuk biaya I/O yang berpotensi lebih tinggi dengan Parallel Query. Pertama, meskipun beberapa data dalam tabel berada dalam kumpulan buffer, Parallel Query mengharuskan agar semua data dipindai pada lapisan penyimpanan, menimbulkan I/O. Kedua, efek samping menghindari ketidaksesuaian dalam kumpulan buffer adalah operasi kueri Parallel Query yang tidak akan membuat kumpulan buffer panas. Akibatnya, menjalankan kueri Parallel Query yang sama berturut-turut akan menimbulkan biaya I/O penuh.

Pelajari selengkapnya tentang Parallel Query in the Documentation.

Tidak. Untuk saat ini, Anda dapat menggunakan Parallel Query dengan instans dalam keluarga instans R*.

Pada awalnya tidak. Untuk saat ini, Anda hanya dapat mengaktifkannya untuk klaster basis data yang tidak menjalankan fitur Nirserver atau Backtrack. Kedepannya, Parallel Query tidak mendukung fungsionalitas khusus untuk Aurora dengan kompatibilitas MySQL 5.7.

Tidak. Meskipun kami berharap Parallel Query dapat meningkatkan latensi kueri di sebagian besar kasus, tetapi Anda mungkin dikenai biaya I/O yang lebih tinggi. Kami merekomendasikan Anda untuk menguji beban kerja Anda secara cermat dengan cara mengaktifkan dan menonaktifkan fitur tersebut. Setelah Anda yakin bahwa Parallel Query adalah pilihan yang tepat, Anda dapat bergantung pada pengoptimal kueri untuk secara otomatis menentukan kueri mana yang akan menggunakan Parallel Query. Dalam kasus yang jarang terjadi, saat pengoptimal tidak membuat penentuan yang optimal, Anda dapat mengganti pengaturan tersebut.

Aurora Parallel Query bukanlah gudang data dan tidak memberikan fungsionalitas yang biasa ditemukan dalam produk serupa. Fitur ini dirancang untuk mempercepat performa kueri pada basis data relasional dan cocok untuk kasus penggunaan seperti analitik operasional, ketika Anda perlu melakukan kueri analitik yang cepat pada data baru dalam basis data Anda.

Untuk gudang data cloud berskala eksabita, harap pertimbangkan Amazon Redshift.

Amazon DevOps Guru untuk RDS adalah kemampuan baru yang didukung ML untuk Amazon RDS (yang mencakup Amazon Aurora) yang dirancang untuk secara otomatis mendeteksi dan mendiagnosis performa basis data dan masalah operasional, sehingga Anda dapat menyelesaikan masalah dalam hitungan menit dan bukan hitungan hari.

Amazon DevOps Guru untuk RDS adalah fitur Amazon DevOps Guru, yang dirancang untuk mendeteksi masalah operasional dan performa untuk semua mesin Amazon RDS dan belasan tipe sumber daya lainnya. DevOps Guru untuk RDS memperluas kemampuan DevOps Guru untuk mendeteksi, mendiagnosis, dan memperbaiki berbagai jenis masalah terkait basis data dalam Amazon RDS (mis., penggunaan sumber daya yang berlebihan, dan kesalahan kueri SQL tertentu).

Ketika terjadi masalah, Amazon DevOps Guru untuk RDS dirancang untuk segera memberi tahu developer dan teknisi DevOps serta menyediakan informasi diagnostik, detail mengenai besarnya masalah, dan rekomendasi perbaikan cerdas untuk membantu pelanggan dengan cepat mengatasi kemacetan performa dan masalah operasional terkait basis data.

Amazon DevOps Guru untuk RDS dirancang untuk menghilangkan upaya manual dan mempersingkat waktu (dari jam dan hari ke menit) dalam mendeteksi dan menyelesaikan kemacetan performa yang sulit ditemukan dalam beban kerja basis data relasional Anda.

Anda dapat mengaktifkan DevOps Guru untuk RDS bagi setiap basis data Amazon Aurora yang akan otomatis mendeteksi masalah performa untuk beban kerja Anda, mengirimkan tanda kepada Anda untuk setiap masalah, menjelaskan temuan, dan merekomendasikan tindakan untuk menyelesaikannya.
DevOps Guru untuk RDS membantu menjadikan administrasi basis data lebih mudah diakses oleh selain ahli dan membantu para ahli basis data agar mereka dapat mengelola lebih banyak basis data.

Amazon DevOps Guru untuk RDS menggunakan ML untuk menganalisis data telemetri yang dikumpulkan oleh Wawasan Performa Amazon RDS (PI). Dalam analisisnya, DevOps Guru untuk RDS tidak menggunakan data Anda yang tersimpan di basis data dalam analisisnya. PI mengukur beban basis data, metrik yang mencirikan bagaimana suatu aplikasi menghabiskan waktu dalam basis data dan metrik pilihan yang dihasilkan oleh basis data tersebut, seperti variabel status server dalam tabel MySQL dan pg_stat di PostgreSQL.

Untuk memulai DevOps Guru untuk RDS, pastikan Wawasan Performa diaktifkan melalui konsol RDS, lalu cukup aktifkan DevOps Guru untuk basis data Amazon Aurora Anda. Dengan DevOps Guru, Anda dapat memilih batas cakupan analisis untuk menjadi seluruh akun AWS Anda, tentukan tumpukan AWS CloudFormation tertentu yang Anda inginkan untuk dianalisis oleh DevOps Guru, atau gunakan tanda AWS untuk membuat grup sumber daya yang Anda inginkan untuk dianalisis oleh DevOps Guru.

Amazon DevOps Guru untuk RDS membantu mengidentifikasi berbagai masalah performa yang dapat memengaruhi kualitas layanan aplikasi, seperti penumpukan kunci, badai koneksi, regresi SQL, ketidakcocokan CPU dan I/O, dan masalah memori.

Wawasan Performa Amazon RDS adalah fitur penyetelan dan pemantauan performa basis data yang mengumpulkan dan memvisualisasikan metrik performa basis data Amazon RDS, membantu Anda dengan cepat menilai muatan di basis data, dan menentukan waktu dan tempat untuk mengambil tindakan. Amazon DevOps Guru untuk RDS dirancang untuk memantau metrik-metrik tersebut, mendeteksi ketika basis data Anda sedang mengalami masalah performa, menganalisis metrik, lalu memberi tahu Anda masalahnya dan tindakan yang dapat Anda lakukan.