Umum

T: Apa itu Amazon Aurora?

Amazon Aurora adalah mesin database relasional yang menggabungkan kecepatan dan keandalan database komersial kelas atas dengan kesederhanaan dan penghematan biaya database sumber terbuka. MySQL Amazon Aurora memberikan hingga lima kali lipat kinerja MySQL tanpa memerlukan perubahan apa pun ke sebagian besar aplikasi MySQL; demikian pula, PostgreSQL Amazon Aurora yang memberikan hingga tiga kali kinerja PostgreSQL. Amazon RDS mengelola database Amazon Aurora Anda, mengelola tugas yang memakan waktu seperti penyediaan, patching, pencadangan, pemulihan, pendeteksian kegagalan, dan perbaikan. Anda cukup membayar biaya bulanan untuk setiap instans database Amazon Aurora yang Anda gunakan. Tidak ada biaya di muka atau komitmen jangka panjang yang diperlukan.

T: Apa yang dimaksud dengan "kompatibel dengan MySQL"?

Ini berarti sebagian besar kode, aplikasi, driver, dan alat yang sudah Anda gunakan saat ini dengan database MySQL dapat digunakan bersama Aurora dengan sedikit atau tanpa perubahan. Mesin database Amazon Aurora dirancang agar kompatibel dengan MySQL 5.6 dan 5.7 menggunakan mesin penyimpanan InnoDB. Fitur MySQL tertentu seperti mesin penyimpanan MyISAM tidak tersedia dengan Amazon Aurora.

T: Apa yang dimaksud dengan "kompatibel dengan PostgreSQL"?

Artinya, sebagian besar kode, aplikasi, driver, dan alat yang sudah Anda gunakan saat ini dengan database PostgreSQL dapat digunakan bersama Aurora dengan sedikit atau tanpa perubahan. Mesin database Amazon Aurora dirancang agar kompatibel dengan PostgreSQL 9.6 dan 10, dan mendukung kumpulan ekstensi PostgreSQL serupa yang didukung dengan RDS untuk PostgreSQL 9.6 dan 10, mempermudah pemindahan aplikasi antara dua mesin.  

T: Bagaimana cara mencoba Amazon Aurora?

Untuk mencoba Amazon Aurora, masuk ke konsol AWS, pilih RDS di bawah kategori Database, lalu pilih Amazon Aurora sebagai mesin database Anda.

T: Berapa biaya Amazon Aurora?

Silakan baca halaman harga kami untuk informasi harga saat ini.

T. Amazon Aurora mereplikasi setiap bagian volume database saya dengan enam cara di seluruh Availability Zone. Apakah itu berarti harga penyimpanan efektif saya akan menjadi tiga atau enam kali lipat dari yang ditampilkan pada halaman harga?

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

T. Di wilayah AWS mana Amazon Aurora tersedia?

Silakan baca halaman harga kami untuk informasi tentang wilayah dan harga saat ini.

T: Bagaimana cara bermigrasi dari MySQL ke Amazon Aurora dan sebaliknya?

Anda memiliki 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 memindahkan Snapshot DB RDS MySQL ke Amazon Aurora menggunakan AWS Management Console. Migrasi untuk sebagian besar pelanggan biasanya selesai dalam waktu kurang dari satu jam, meski durasi tersebut bergantung pada format dan ukuran data set. Untuk informasi selengkapnya lihat Praktik terbaik untuk Melakukan Migrasi Database MySQL ke Amazon Aurora.

T: Bagaimana cara bermigrasi dari PostgreSQL ke Amazon Aurora dan sebaliknya?

Anda memiliki 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 memindahkan Snapshot DB RDS PostgreSQL ke Amazon Aurora menggunakan AWS Management Console. Migrasi untuk sebagian besar pelanggan biasanya selesai dalam waktu kurang dari satu jam, meski durasi tersebut bergantung pada format dan ukuran data set.

T: Apakah Amazon Aurora berpartisipasi dalam AWS Tingkat Gratis?

Tidak pada saat ini. AWS Tingkat Gratis untuk Amazon RDS menawarkan keuntungan untuk Instans Micro DB; Amazon Aurora saat ini tidak memberikan dukungan Instans Micro DB. Silakan baca halaman harga kami untuk informasi harga saat ini.

T: Apa yang dimaksud IO di Amazon Aurora dan bagaimana hal tersebut dihitung?

IO adalah operasi input/output yang dilakukan mesin database Aurora pada lapisan penyimpanan virtual berbasis SSD miliknya. Setiap operasi baca halaman database dihitung sebagai satu IO. Mesin database Aurora mengeluarkan baca pada lapisan penyimpanan untuk mengambil halaman database yang tidak tersedia dalam cache buffer. Setiap halaman database berukuran 16 KB pada MySQL Aurora dan 8 KB pada PostgreSQL.

Aurora dirancang untuk menghapus operasi IO yang tidak diperlukan guna mengurangi biaya serta memastikan sumber daya tersedia untuk melakukan lalu lintas baca/tulis. IO tulis hanya digunakan saat mendorong catatan log transaksi ke lapisan penyimpanan agar operasi tulis tahan lama. IO tulis dihitung dalam unit 4 KB. Contohnya, catatan log transaksi yang berukuran 1024 bytes akan dihitung sebagai satu operasi IO. Meski begitu, operasi tulis yang terjadi bersamaan yang memiliki log transaksi berukuran kurang dari 4 KB dapat di-batch bersama dengan mesin database Aurora untuk mengoptimalkan konsumsi I/O. Tidak seperti mesin database tradisional, Amazon Aurora tidak mendorong halaman database yang diubah ke lapisan penyimpanan, yang menghasilkan penghematan konsumsi IO lebih banyak.

Anda dapat melihat berapa banyak IO yang dikonsumsi instans Aurora Anda dengan membuka Konsol AWS. Untuk mencari tahu konsumsi IO Anda, buka bagian RDS konsol, lihat daftar instans Anda, pilih instans Aurora, kemudian cari metrik “Operasi baca tertagih” dan “Operasi tulis tertagih” di bagian pemantauan.

T: Apakah saya perlu mengubah driver klien untuk menggunakan PostgreSQL Amazon Aurora?

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

Kinerja

T: Apa yang dimaksud dengan "lima kali kinerja MySQL"?

Amazon Aurora memberikan peningkatan signifikan atas kinerja MySQL dengan mengintegrasikan mesin database dengan lapisan virtual berbasis SSD yang dibuat khusus untuk beban kerja database, mengurangi tulis pada sistem penyimpanan, meminimalkan ketidaksesuaian dan mengurangi penundaan yang dibuat utas proses database. Tes kami dengan SysBench pada instans r3.8xlarge menunjukkan bahwa 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 terperinci tentang benchmark ini dan cara untuk mereplikasinya sendiri tersedia dalam Panduan Benchmark Kinerja MySQL Amazon Aurora.

T: Apa yang dimaksud dengan "tiga kali kinerja PostgreSQL"?

Amazon Aurora memberikan peningkatan signifikan atas kinerja PostgreSQL dengan mengintegrasikan mesin database dengan lapisan virtual berbasis SSD yang dibuat khusus untuk beban kerja database, mengurangi tulis pada sistem penyimpanan, meminimalkan ketidaksesuaian dan mengurangi penundaan yang dibuat utas proses database. Tes kami dengan SysBench pada instans r4.16xlarge menunjukkan bahwa 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 benchmark ini dan cara untuk mereplikasinya sendiri tersedia dalam Panduan Benckmark Kinerja PostgreSQL Amazon Aurora.

T: Bagaimana cara mengoptimalkan beban kerja database untuk MySQL Amazon Aurora?

Amazon Aurora dirancang agar kompatibel dengan MySQL, sehingga aplikasi dan alat MySQL yang ada dapat berjalan tanpa modifikasi. Meski begitu, satu area di mana Amazon Aurora meningkat pada 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 konkuren dalam jumlah besar.

T: Bagaimana cara mengoptimalkan beban kerja database untuk PostgreSQL Amazon Aurora?

Amazon Aurora dirancang agar kompatibel dengan PostgreSQL, sehingga aplikasi dan alat PostgreSQL yang ada dapat berjalan tanpa modifikasi. Meski begitu, satu area di mana Amazon Aurora meningkat pada PostgreSQL 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 konkuren dalam jumlah besar.

Perangkat Keras dan Penskalaan

T: Berapa batas penyimpanan minimum dan maksimum database Amazon Aurora?

Penyimpanan minimum adalah 10 GB. Berdasarkan penggunaan database Anda, penyimpanan Amazon Aurora akan otomatis berkembang, hingga 64 TB, dalam peningkatan 10 GB tanpa berdampak pada kinerja database. Tidak perlu menyediakan penyimpanan lanjutan.

T: Bagaimana cara menskalakan sumber daya komputasi yang terhubung dengan instans DB Amazon Aurora?

Anda dapat menskalakan sumber daya komputasi yang dialokasikan untuk instans DB Anda dalam AWS Management Console dengan memilih instans DB yang diinginkan dan mengklik tombol Modifikasi. Sumber daya memori dan CPU diubah dengan mengubah kelas Instans DB Anda.

Ketika Anda memodifikasi kelas Instans DB Anda, perubahan yang Anda minta akan diterapkan selama periode pemeliharaan yang ditentukan. Cara lainnya, Anda dapat menggunakan bendera "Terapkan Segera" untuk segera menerapkan permintaan penskalaan Anda. Kedua opsi ini akan memiliki pengaruh ketersediaan selama beberapa menit saat operasi penskalaan dilakukan. Ingat bahwa perubahan sistem yang tertunda lainnya juga akan diterapkan.

Pencadangan dan Pemulihan

T: Bagaimana cara mengaktifkan cadangan untuk Instans DB saya?

Pencadangan otomatis selalu diaktifkan pada Instans DB Amazon Aurora. Pencadangan tidak memengaruhi kinerja database.

T: Dapatkah saya mengambil Snapshot DB dan menyimpannya selama yang saya bisa?

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

T: Jika database saya gagal, bagaimana jalur pemulihan saya?

Amazon Aurora secara otomatis memelihara 6 salinan data di 3 Availability Zone dan secara otomatis mencoba untuk memulihkan database 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 yang dapat dipulihkan terakhir untuk operasi pemulihan waktu tertentu adalah hingga 5 menit yang lalu.

T: Apa yang terjadi dengan cadangan otomatis dan Snapshot DB saya jika saya menghapus Instans DB?

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 menyimpan Snapshot DB buatan pengguna terakhir ini bersama dengan semua Snapshot DB yang dibuat secara manual setelah Instans DB dihapus. Hanya Snapshot DB yang disimpan setelah Instans DB dihapus (artinya, cadangan otomatis yang dibuat untuk pemulihan waktu tertentu tidak disimpan).

T: Dapatkah saya membagikan snapshot dengan akun AWS lain?

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, pengembangan/tes, pentahapan, 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.

T: Apakah saya akan dikenakan biaya untuk snapshot yang dibagikan?

Tidak ada biaya untuk berbagi snapshot antar akun. Namun, Anda mungkin dikenakan biaya atas snapshot itu sendiri, dan juga database yang Anda pulihkan dari snapshot yang dibagikan. Pelajari selengkapnya tentang harga Aurora.

T: Dapatkah saya berbagi snapshot secara otomatis?

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

T: Dengan berapa banyak akun saya dapat berbagi snapshot?

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

T: Di wilayah mana saya dapat berbagi snapshot Aurora?

Anda dapat berbagi snapshot Aurora di semua wilayah AWS di mana Aurora tersedia.

T. Dapatkah saya berbagi snapshot Aurora di wilayah yang berbeda?

Tidak. Snapshot Aurora bersama Anda hanya dapat diakses dengan akun yang berada dalam wilayah yang sama dengan akun yang membagikannya.

T: Dapatkah saya berbagi snapshot Aurora yang dienkripsi?

Ya, Anda dapat berbagi snapshot Aurora yang dienkripsi.

Ketersediaan dan Replikasi yang Sangat Baik

T: Bagaimana cara Amazon Aurora meningkatkan toleransi kesalahan database saya atas kegagalan disk?

Amazon Aurora secara otomatis membagi volume database Anda menjadi 10 GB segmen yang tersebar di beberapa disk. Setiap 10 GB bagian volume database Anda direplikasi dengan enam cara di tiga Availability Zone. Amazon Aurora dirancang untuk menangani kehilangan hingga dua salinan data tanpa memengaruhi ketersediaan tulis database dan hingga tiga salinan tanpa memengaruhi ketersediaan baca. Penyimpanan Amazon Aurora juga dapat pulih dengan sendirinya. Blok data dan disk terus dipindai untuk mencari kesalahan dan akan otomatis diperbaiki.

T: Bagaimana cara Aurora meningkatkan waktu pemulihan setelah database crash?

Tidak seperti database lain, setelah database crash, Amazon Aurora tidak perlu memutar ulang log pengulangan dari titik pemeriksaan database terakhir (biasanya 5 menit) dan mengonfirmasi bahwa semua telah diterapkan, sebelum membuat database tersedia untuk operasi. Hal ini mengurangi waktu restart database 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. Hal ini mencegah Anda harus membatasi akses hingga cache kembali dipenuhi untuk menghindari ketidaktersediaan.

T: Replika apa yang didukung Aurora?

Amazon Aurora MySQL dan Amazon Aurora PostgreSQL mendukung Replika Amazon Aurora, yang memiliki volume dasar yang sama sebagai instans primer di wilayah AWS yang sama. Pembaruan yang dibuat oleh primer terlihat pada semua Replika Amazon Aurora. Dengan MySQL Amazon Aurora, Anda juga dapat membuat Replika Baca MySQL berdasarkan mesin replikasi berbasis binlog MySQL. Pada Replika Baca MySQL, data dari instans utama Anda akan diputar kembali pada replika Anda sebagai transaksi. Untuk sebagian besar kasus penggunaan, termasuk penskalaan baca dan ketersediaan yang sangat baik, kami menyarankan Anda menggunakan Replika Amazon Aurora.

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

Fitur Replika Amazon Aurora
Replika MySQL
Jumlah replika Hingga 15 Hingga 5
Jenis replikasi Asinkron (milidetik) Asinkron (detik)
Pengaruh kinerja pada primer Rendah Tinggi
Bertindak sebagai target failover Ya (tidak ada kehilangan data) Ya (berpotensi bermenit-menit kehilangan data)
Failover otomatis Ya Tidak
Dukungan untuk penundaan replikasi yang ditetapkan pengguna Tidak Ya
Dukungan untuk data atau skema berbeda vs. primer Tidak Ya

T. Dapatkah saya memiliki replika lintas wilayah dengan Amazon Aurora?

Ya, dengan MySQL Aurora, Anda dapat membuat Replika Aurora lintas wilayah menggunakan replikasi logika atau fisik.

Replikasi logika dapat mereplikasi hingga lima wilayah AWS sekunder, dan didasarkan pada replikasi binlog MySQL berutas tunggal, sehingga lag replikasi akan dipengaruhi oleh tingkat perubahan/penerapan serta penundaan dalam komunikasi jaringan antarwilayah khusus yang dipilih. Replikasi fisik, yang disebut Aurora Global Database, menggunakan infrastruktur khusus yang membuat database Anda tersedia sepenuhnya untuk menyokong aplikasi, dan dapat mereplikasi ke satu wilayah sekunder dengan latensi umum di bawah satu detik. Untuk pembacaan global latensi rendah dan pemulihan bencana, kami menyarankan untuk menggunakan Global Database.

Aurora PostgreSQL saat ini belum mendukung replika lintas wilayah.

T. Dapatkah saya membuat Replika Baca Aurora pada klaster replika antarwilayah?

Ya, Anda dapat menambahkan hingga 15 Replika Aurora pada tiap klaster lintas wilayah, dan 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 10 milidetik di belakang primer.

T. Dapatkah saya mengalihkan aplikasi dari primer saat ini ke replika lintas wilayah?

Ya, Anda dapat mengembangkan replika lintas wilayah menjadi primer baru dari konsol 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 Aurora Global Database, Anda dapat mempromosikan wilayah sekunder untuk melakukan beban kerja baca/tulis dalam waktu kurang dari satu menit.

T: Dapatkah saya memprioritaskan replika tertentu sebagai target failover atas replika lainnya?

Ya. Anda dapat menetapkan tingkat prioritas promosi untuk setiap instans pada klaster Anda. Saat primer gagal, Amazon RDS akan mempromosikan replika dengan prioritas tertinggi menjadi primer. Jika terdapat ketidaksesuaian antara 2 replika atau lebih dalam tingkat prioritas yang sama, Amazon RDS akan mempromosikan replika dengan ukuran yang sama seperti instans primer. Untuk informasi selengkapnya tentang logika failover, baca Panduan Pengguna Amazon Aurora.

T: Dapatkah saya mengubah tingkat prioritas untuk instans setelah dibuat?

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

T: Dapatkah saya mencegah replika tertentu dipromosikan menjadi instans primer?

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.

T: Bagaimana cara meningkatkan ketersediaan satu database Amazon Aurora?

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 database, cukup buat 1 hingga 15 replika, di salah satu dari 3 AZ, lalu Amazon RDS akan otomatis menyertakan mereka dalam pilihan primer failover saat sebuah database mati.

Anda dapat menggunakan Aurora Global Database jika ingin agar database menjangkau beberapa Wilayah AWS. Ini akan mereplikasi data Anda tanpa berpengaruh pada kinera database, dan memberikan pemulihan bencana dari pemadaman dalam lingkup wilayah.

T: Apa yang terjadi selama failover dan berapa lama waktu yang diperlukan?

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

  • Jika Anda memiliki Replika Amazon Aurora, dalam Availability Zone yang sama atau berbeda, saat failover, Aurora akan membalikkan catatan nama resmi (CNAME) bagi Instans DB Anda untuk menunjuk replika yang sehat, yang pada saatnya dipromosikan untuk menjadi primer baru. Dari awal hingga selesai, failover biasanya selesai dalam 30 detik.
  • Jika Anda tidak memiliki Replika Amazon Aurora (yaitu satu instans), Aurora pertama-tama akan mencoba untuk membuat Instans DB baru dalam Availability Zone yang sama dengan instans asli. Jika tidak bisa, Aurora akan mencoba untuk membuat Instans DB di Availability Zone yang berbeda. Dari awal hingga selesai, failover biasanya selesai kurang dari 15 menit.

Aplikasi Anda harus mencoba ulang koneksi database jika terjadi kehilangan koneksi.

Pemulihan bencana di seluruh wilayah adalah proses manual, di mana Anda mempromosikan wilayah sekunder untuk mengambil beban kerja baca/tulis.

T: Jika saya memiliki database primer dan satu Replika Amazon Aurora secara aktif membaca lalu lintas lalu failover terjadi, apa yang terjadi?

Amazon RDS akan otomatis mendeteksi masalah dengan instans primer Anda dan mulai merutekan lalu lintas baca/tulis Anda ke Replika Amazon Aurora. Rata-rata, failover ini akan selesai dalam 30 detik. Selain itu, lalu lintas baca yang disediakan Replika Aurora Anda akan terputus sebentar.

T: Seberapa lama replika saya akan tertinggal di belakang primer?

Karena Replika Amazon Aurora memiliki volume data yang sama dengan instans primer di Wilayah AWS yang sama, tidak akan ada lag replikasi secara virtual. Kami biasanya mengamati waktu lag dalam 10 milidetik. Untuk Replika Baca MySQL, lag replikasi bisa meningkat tak tentu berdasarkan tingkat perubahan/penerapan dan juga penundaan dalam komunikasi jaringan. Namun, dalam kondisi umum, lag replikasi di bawah satu menit adalah hal yang biasa.

Replika lintas wilayah yang menggunakan replikasi logika akan dipengaruhi oleh tingkat perubahan/penerapan serta penundaan dalam komunikasi jaringan antarwilayah khusus yang dipilih. Replika lintas wilayah yang menggunakan Aurora Global Database akan memiliki lag umumnya kurang dari satu detik.

T: Apa itu Amazon Aurora Global Database?

Amazon Aurora Global Database adalah fitur yang memungkinkan satu database Amazon Aurora menjangkau beberapa wilayah AWS. Fitur ini mereplikasi data Anda tanpa berpengaruh pada kinerja database, 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 1 menit.

Fitur ini tersedia untuk Amazon Aurora MySQL.

T: Bagaimana cara membuat Aurora Global Database?

Anda dapat membuat Aurora Global Database hanya dengan beberapa klik di Konsol Amazon RDS Management. Sebagai alternatif, Anda dapat menggunakan SDK atau CLI. Anda perlu menyediakan setidaknya satu instans per wilayah di Aurora Global Database Anda.

T: Jika menggunakan Aurora Global Database, apakah saya juga dapat menggunakan replikasi logika (binlog) pada database primer?

Ya. Jika tujuan Anda adalah untuk menganalisis aktivitas database, pertimbangkan untuk menggunakan audit lanjutan Aurora, log umum, dan log kueri lambat sebagai gantinya untuk mencegah memengaruhi kinerja database.

T: Apakah Aurora akan secara otomatis melakukan fail over ke wilayah sekunder Aurora Global Database?

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

T: Apa itu Amazon Aurora Multi-Master?

Amazon Aurora Multi-Master adalah fitur baru edisi Aurora yang kompatibel dengan MySQL yang menambahkan kemampuan untuk menskalakan kinerja tulis di banyak Availability Zone, memungkinkan aplikasi mengarahkan beban kerja baca/tulis ke banyak instans di klaster database dan beroperasi dengan ketersediaan yang sangat baik.

T: Apa yang harus saya lakukan untuk memulai dengan Amazon Multi-Master?

Amazon Aurora Multi-Master sekarang tersedia dalam Pratinjau untuk edisi Amazon Aurora yang kompatibel dengan MySQL. Anda dapat mendaftar untuk meminta partisipasi. Kami akan mengumumkan ketersediaan umum dalam waktu mendatang.

Keamanan

T: Dapatkah saya menggunakan Amazon Aurora di Amazon Virtual Private Cloud (Amazon VPC)?

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 database Amazon Aurora Anda.

T: Apakah Amazon Aurora mengenkripsi data saya dalam transit dan saat istirahat?

Ya. Amazon Aurora menggunakan SL (AES-256) untuk mengamankan koneksi antar instans database dan aplikasi. Amazon Aurora memungkinkan Anda mengenkripsi database menggunakan kunci yang Anda kelola melalui AWS Key Management Service (KMS). Pada instans database yang berjalan dengan enkripsi Amazon Aurora, data yang disimpan saat istirahat di penyimpanan dasar dienkripsi, begitu juga cadangan otomatis, snapshot dan replika dalam klaster yang sama. Enkripsi dan dekripsi ditangani dengan mulus. Untuk informasi lebih lanjut tentang penggunaan KMS dengan Amazon Aurora, lihat Panduan Pengguna Amazon RDS.

T: Dapatkah saya mengenkripsi database tak terkenkripsi yang sudah ada?

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

T: Bagaimana cara mengakses database Amazon Aurora saya?

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

T: Dapatkah saya menggunakan Amazon Aurora dengan aplikasi yang memerlukan kepatuhan HIPAA?

Ya, edisi Aurora yang kompatibel dengan MySQL dan PostgreSQL memenuhi syarat HIPAA, sehingga Anda dapat menggunakannya untuk membuat aplikasi sesuai dengan HIPAA dan menyimpan informasi yang berhubungan dengan kesehatan, termasuk informasi kesehatan yang dilindungi (PHI) di bawah Business Associate Agreement (BAA) dengan AWS. Jika Anda telah memiliki BAA yang telah dieksekusi, tidak ada tindakan yang perlu dilakukan untuk memulai menggunakan layanan ini di akun yang dicakup oleh BAA Anda. Jika Anda tidak memiliki BAA yang telah dijalankan dengan AWS, atau memiliki pertanyaan lain tentang aplikasi yang sesuai dengan HIPAA pada AWS, silakan hubungi kami.

Tanpa Server

T: Apa itu Amazon Aurora Tanpa Server?

Amazon Aurora Tanpa Server adalah konfigurasi penskalaan otomatis sesuai pesanan untuk edisi Amazon Aurora yang kompatibel dengan MySQL. Klaster DB Aurora Tanpa Server secara otomatis dimulai, nonaktif, dan menaikkan atau menurunkan skala kapasitas berdasarkan kebutuhan aplikasi Anda. Aurora Tanpa Server memberikan opsi hemat biaya yang relatif sederhana untuk beban kerja jarang, terputus-putus, atau tak terrduga. Baca selengkapnya di Panduan Pengguna Amazon Aurora.

T: Versi Amazon Aurora mana yang didukung Aurora Tanpa Server?

Aurora Tanpa Server saat ini tersedia untuk Aurora dengan kompatibilitas MySQL 5.6.

T: Dapatkah saya memindahkan klaster DB Aurora yang sudah ada ke Aurora Tanpa Server?

Ya, Anda dapat memulihkan snapshot dari klaster terprovisi Aurora yang sudah ada ke Klaster DB Aurora Tanpa Server (dan sebaliknya).

T: Bagaimana cara tersambung ke klaster DB Aurora Tanpa Server?

Anda dapat mengakses klaster DB Aurora Tanpa Server dari dalam aplikasi klien yang berjalan dalam Amazon Virtual Private Cloud (VPC) yang sama. Anda tidak dapat memberikan klaster DB Aurora Tanpa Server sebuah alamat IP publik.

T: Dapatkah saya mengatur kapasitas klaster Aurora Tanpa Server secara eksplisit?

Sementara Aurora Tanpa Server melakukan penskalaan berdasarkan beban kerja database yang aktif, dalam beberapa kasus, kapasitas mungkin tidak diskalakan cukup cepat untuk memenuhi perubahan beban kerja mendadak, seperti transaksi baru jumlah besar. Dalam kasus ini, Anda dapat mengatur kapasitas secara eksplisit hingga nilai tertentu dengan AWS Management Console, AWS CLI, atau API RDS.

T: Mengapa Klaster DB Aurora Tanpa Server saya tidak otomatis diskalakan?

Setelah operasi penskalaan dimulai, Aurora Tanpa Server mencoba untuk menemukan titik penskalaan, yang merupakan titik di mana database dapat diskalakan penuh dengan aman. Aurora Tanpa Server mungkin tidak dapat menemukan titik penskalaan jika Anda memiliki kueri yang berjalan panjang atau transaksi yang sedang berjalan, atau tabel sementara atau tabel terkunci yang digunakan.

T: Bagaimana saya dikenai biaya atas Aurora Tanpa Server?

Dalam Aurora Tanpa Server, kapasitas database diukur dalam Unit Kapasitas Aurora (ACU). Anda cukup membayar harga tetap per detik penggunaan ACU, dengan minimal 5 menit penggunaan setiap database diaktifkan. Harga penyimpanan dan I/O sama dengan konfigurasi terprovisi dan Tanpa Server. Lihat contoh harga Aurora Tanpa Server.

Parallel Query

T: Apa itu Amazon Aurora Parallel Query?

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 database Amazon Aurora akan dieksekusi sepenuhnya dalam satu instans klaster database; hal ini mirip dengan bagaimana sebagian besar database beroperasi.

T: Bagaimana kasus penggunaan target?

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

T: Apa keuntungan yang diberikan Parallel Query?

Kinerja lebih kencang: Parallel Query dapat meningkatkan kecepatan kueri analisis sebesar 2 urutan magnitudo.

Kesederhanaan operasional dan kesegaran data: Anda dapat mengeluarkan kueri secara langsung atas data transaksional saat ini dalam klaster Aurora Anda.

Beban kerja transaksional dan analisis pada database yang sama: Parallel Query memungkinkan Aurora untuk menjaga throughput transaksi tinggi bersama dengan kueri analisis konkuren.

T: Kueri spesifik apa yang meningkat di bawah Parallel Query?

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

T: Peningkatan kinerja seperti apa yang dapat saya harapkan?

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

T: Apakah ada kemungkinan kinerjanya akan jadi lebih lambat?

Ya, namun kami memperkirakan kasus tersebut jarang terjadi.

T: Perubahan apa yang perlu dilakukan pada kueri saya agar dapat memanfaatkan Parallel Query?

Tidak ada perubahan dalam sintaksis kueri yang perlu dilakukan. Pengoptimal kueri akan otomatis menentukan apakah akan menggunakan PQ pada kueri tertentu. Untuk memeriksa apakah sebuah kueri menggunakan PQ, 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.

T: Bagaimana cara mengaktifkan dan menonaktifkan fitur tersebut?

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

T: Apakah terdapat biaya tambahan terkait dengan penggunaan Parallel Query?

Tidak ada. Anda tidak dikenakan biaya apa pun selain dari apa yang sudah Anda bayar untuk instans, IO, dan penyimpanan.

T: Karena Parallel Query mengurangi IO, apakah pengaktifannya akan mengurangi biaya IO Aurora saya?

Tidak, biaya IO untuk kueri Anda dihitung pada lapisan penyimpanan, dan akan sama atau lebih besar dengan Parallel Query yang aktif. Keuntungan Anda adalah peningkatan kinerja kueri.

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

T: Versi Amazon Aurora mana yang mendukung Parallel Query?

Parallel Query tersedia untuk versi Amazon Aurora yang kompatibel dengan MySQL 6.6, dimulai dengan v1.18.0. Kami berencana untuk memperluas Parallel Query ke Aurora dengan kompatibilitas MySQL 5.7, serta Aurora dengan kompatibilitas PostgreSQL.

T: Apakah Parallel Query tersedia dengan semua jenis instans?

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

T: Apakah Parallel Query kompatibel dengan semua fitur Aurora?

Pada awalnya tidak. Untuk saat ini, Anda hanya dapat mengaktifkannya untuk klaster database yang tidak menjalankan fitur Tanpa Server atau Menarik Kembali. Kedepannya, Parallel Query tidak mendukung fungsionalitas khusus untuk Aurora dengan kompatibilitas MySQL 5.7.

T: Jika Parallel Query meningkatkan kecepatan kueri hanya dengan kehilangan kinerja yang jarang, haruskah saya mengaktifkannya sepanjang waktu?

Tidak. Sementara kami berharap Parallel Query meningkatkan latensi kueri di sebagian besar kasus, Anda mungkin dikenai biaya IO yang lebih tinggi. Kami menyarankan Anda untuk benar-benar menguji beban kerja Anda dengan mengaktifkan dan menonaktifkan fitur ini, setelah Anda yakin bahwa Parallel Query adalah pilihan yang tepat, Anda dapat bergantung pada pengoptimal kueri agar otomatis menentukan kueri mana yang akan menggunakan PQ. Dalam kasus yang jarang terjadi, saat pengoptimal tidak membuat penentuan yang optimal, Anda dapat mengganti pengaturannya.

T: Dapatkah Parallel Query mengganti gudang data saya?

Aurora Parallel Query bukanlah gudang data, dan tidak memberikan fungsionalitas yang biasa ditemukan dalam produk serupa. Fitur ini dirancang untuk meningkatkan kecepatan kinerja kueri pada database relasional, dan cocok untuk kasus penggunaan seperti analisis operasional, ketika Anda perlu melakukan kueri analisis cepat pada data segar dalam database Anda.

Pelajari selengkapnya tentang harga Amazon Aurora

Kunjungi halaman harga
Siap membuat?
Memulai dengan Amazon Aurora
Punya pertanyaan lainnya?
Hubungi kami