Umum

T: Apa itu Amazon Aurora?

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

Aurora mengutamakan sistem penyimpanan yang terdistribusi, toleran terhadap kesalahan, dan dapat melakukan pemulihan mandiri yang otomatis meningkatkan skala sampai 128 TB per instans basis data. Ia memberikan kinerja dan ketersediaan yang sangat baik sampai 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 mengotomatisasi tugas-tugas administrasi yang menghabiskan waktu seperti penyediaan perangkat keras, penyiapan basis data, dan cadangan sembari menyediakan keamanan, ketersediaan, dan keandalan basis data komersial dengan biaya hanya 1/10 nya.

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

Amazon Aurora kompatibel sepenuhnya dengan basis data sumber terbuka MySQL yang ada, dan secara rutin menambah dukungan untuk rilisan baru. Ini berarti Anda dapat secara mudah memindahkan basis data MySQL ke dan dari Aurora menggunakan alat impor/ekspor atau snapshot standar. Hal ini 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. Saat mempertimbangkan Aurora vs. Mesin basis data Amazon Aurora dirancang agar kompatibel dengan MySQL 5.6 dan 5.7 menggunakan mesin penyimpanan InnoDB. Hal ini memudahkan untuk memindahkan aplikasi antara dua mesin. Fitur MySQL tertentu seperti mesin penyimpanan MyISAM tidak tersedia dengan Amazon Aurora.

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

Amazon Aurora kompatibel sepenuhnya dengan basis data sumber terbuka PostgreSQL yang ada, dan secara rutin menambah dukungan untuk rilisan baru. Ini berarti Anda dapat secara mudah memindahkan basis data PostgreSQL ke dan dari Aurora menggunakan alat impor/ekspor atau snapshot standar. Ini juga artinya 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. 

T: Bagaimana sebaiknya saya menganggap Amazon Aurora vs. Amazon Relational Database Service (Amazon RDS)?

J: Amazon RDS adalah layanan basis data terkelola penuh dengan ketersediaan tinggi dan aman yang memudahkan untuk menyiapkan, mengoperasikan, dan menjalankan mesin basis data relasional pilihan Anda: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Amazon Aurora Edisi Kompatibel MySQL, dan Amazon Aurora Edisi Kompatibel PostgreSQL. 

Amazon Aurora Edisi Kompatibel MySQL dan Amazon Aurora Edisi Kompatibel PostgreSQL memanfaatkan Amazon RDS, termasuk mengotomatisasi tugas-tugas administrasi basis data yang menghabiskan waktu, dan menyediakan performa lebih baik, skalabilitas, dan ketersediaan dibandingkan MySQL dan PostgreSQL sumber terbuka komunitas.

T: Bagaimana cara mencoba 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.

T: Berapa biaya Amazon Aurora?

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

T: Amazon Aurora mereplikasi setiap bagian volume basis data saya dengan enam cara di seluruh Zona Ketersediaan. 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 Aurora 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 Amazon RDS for MySQL ke Amazon Aurora menggunakan Konsol Manajemen AWS. 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 basis data 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 Amazon RDS for PostgreSQL ke Amazon Aurora menggunakan Konsol Manajemen AWS. Migrasi untuk sebagian besar pelanggan biasanya selesai dalam waktu kurang dari satu jam, meski durasi tersebut bergantung pada format dan ukuran data set. Untuk memigrasikan aplikasi SQL Server ke Aurora Edisi Kompatibel PostgreSQL, Anda dapat menggunakan Babelfish untuk Aurora PostgreSQL. Buka halaman fitur Babelfish untuk informasi selengkapnya.

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 Aurora untuk informasi harga saat ini.

T: Apa yang dimaksud I/O di Amazon Aurora dan bagaimana penghitungannya?

I/O adalah operasi input/output yang dilakukan mesin basis data Aurora pada lapisan penyimpanan virtual berbasis SSD miliknya. Tiap operasi baca halaman basis data dihitung sebagai satu I/O. Mesin basis data Aurora mengeluarkan baca 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 dirancang untuk menghapus operasi I/O yang tidak diperlukan untuk 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 tulis 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 dikonsumsi instans Aurora Anda dengan membuka Konsol Manajemen AWS. Anda dapat melihat berapa banyak permintaan I/O yang dikonsumsi instans Aurora Anda dengan membuka konsol. Untuk mencari tahu konsumsi 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.

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

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

Kinerja

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

Amazon Aurora memberikan peningkatan signifikan atas performa MySQL dengan mengintegrasikan mesin basis data dengan lapisan virtual berbasis SSD yang dibuat khusus untuk beban kerja basis data, mengurangi tulis 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.

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

Amazon Aurora memberikan peningkatan signifikan atas kinerja PostgreSQL dengan mengintegrasikan mesin basis data dengan lapisan virtual berbasis SSD yang dibuat khusus untuk beban kerja basis data, mengurangi tulis 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 .

T: Bagaimana cara mengoptimalkan beban kerja basis data untuk Amazon Aurora Edisi Kompatibel MySQL?

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 basis data untuk Amazon Aurora Edisi Kompatibel PostgreSQL ?

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 workload 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 basis data Amazon Aurora?

Penyimpanan minimum adalah 10 GB. Berdasarkan penggunaan basis data Anda, penyimpanan Amazon Aurora akan otomatis berkembang, hingga 128 TB, dalam peningkatan 10 GB tanpa berdampak pada kinerja basis data. 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 basis data saya gagal, bagaimana jalur pemulihan saya?

Amazon Aurora secara otomatis memelihara enam salinan data di tiga Zona Ketersediaan 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 yang dapat dipulihkan terakhir untuk operasi pemulihan waktu tertentu adalah hingga lima 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 tempat 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 basis data saya atas kegagalan disk?

Amazon Aurora secara otomatis membagi volume basis data Anda menjadi 10 GB segmen yang tersebar di beberapa disk. Setiap 10 GB bagian volume basis data Anda direplikasi dengan enam cara di tiga Zona Ketersediaan. Amazon Aurora dirancang untuk menangani kehilangan hingga dua salinan data tanpa memengaruhi ketersediaan tulis basis data 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 basis data macet?

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 membuat basis data tersedia 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. Hal ini mencegah Anda harus membatasi akses hingga cache kembali dipenuhi untuk menghindari ketidaktersediaan.

T: Replika apa yang didukung Aurora?

Amazon Aurora Edisi Kompatibel MySQL dan Amazon Aurora Edisi Kompatibel 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 Amazon Aurora Edisi Kompatibel MySQL, Anda juga dapat membuat Replika Baca MySQL antarwilayah 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
Lokasi replika Dalam wilayah
Antarwilayah
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

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

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

Ya, Anda dapat membuat 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. 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 asli di tiap mesin basis data (binlog untuk MySQL dan slot replika PostgreSQL untuk PostgreSQL), jadi Anda bisa mereplika 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. Ini didasarkan pada replikasi binlog MySQL berutas tunggal, sehingga ketertinggalan replikasi akan dipengaruhi tingkat perubahan/pengaplikasian serta penundaan dalam komunikasi jaringan antar wilayah khusus yang dipilih.

T: Dapatkah saya membuat Replika Aurora di klaster replika lintas wilayah?

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 sepuluh milidetik di belakang primer.

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

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 Amazon Aurora Global Database, Anda dapat mempromosikan wilayah sekunder untuk melakukan beban kerja baca/tulis penuh 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 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 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 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. Ini akan mereplikasi data Anda tanpa berpengaruh pada kinerja basis data, 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 basis data sesegera mungkin tanpa intervensi administratif manual.

  • Jika Anda memiliki Replika Amazon Aurora, dalam Zona Ketersediaan 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 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. Disaster recovery di seluruh wilayah adalah proses manual, di mana Anda mempromosikan wilayah sekunder untuk mengambil beban kerja baca/tulis.

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

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 node utama lama dipulihkan sebagai replika.

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 ketertinggalan replikasi secara virtual. Kami biasanya mengamati waktu ketertinggalan dalam sepuluh milidetik. Untuk Replika Baca MySQL, ketertinggalan 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 antarwilayah yang menggunakan Amazon Aurora Global Database akan memiliki ketertinggalan normal kurang dari satu detik.

T: Dapatkah saya mengatur replika antara basis data Aurora Edisi Kompatibel MySQL saya dan basis data MySQL eksternal?

Ya, Anda dapat mengatur replikasi binlog antara instans Aurora Edisi Kompatibel 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 Kompatibel MySQL 5.7, pertimbangkan untuk mengatur replikasi binlog berbasis GTID. Hal ini akan memberikan konsistensi lengkap sehingga Anda tidak akan melewatkan transaksi pada replikasi Anda atau menghasilkan konfilk, bahkan setelah terjadi failover atau waktu henti.

T: Apa itu Amazon Aurora Global Database?

Amazon Aurora Global Database adalah fitur yang memungkinkan satu basis data Amazon Aurora 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.

T: Bagaimana cara membuat Amazon Aurora Global Database?

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

T: Berapa banyak wilayah sekunder yang dapat dimiliki oleh Amazon Aurora Global Database?

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

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

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

T: Apakah Aurora akan secara otomatis melakukan failover ke wilayah sekunder Amazon Aurora Global Database?

Tidak. Jika wilayah primer menjadi tidak tersedia, Anda dapat menghapus wilayah sekunder secara manual dari Amazon 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 Aurora Edisi Kompatibel MySQL yang menambahkan kemampuan untuk menskalakan kinerja tulis di banyak Zona Ketersediaan, memungkinkan aplikasi mengarahkan beban kerja baca/tulis ke banyak instans di klaster basis data dan beroperasi dengan ketersediaan yang sangat baik.

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

Kini Amazon Aurora Multi-Master tersedia untuk umum. Anda dapat membaca dokumentasi Amazon Aurora untuk mempelajari lebih lanjut. Anda dapat membuat klaster Aurora Multi-Master hanya dengan beberapa klik di konsol Amazon RDS atau unduh SDK atau CLI AWS terbaru.

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 basis data 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 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 at rest 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 AWS KMS dengan Amazon Aurora, lihat Panduan Pengguna Amazon RDS.

T: Dapatkah saya mengenkripsi basis data 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 basis data Amazon Aurora saya?

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. Panduan langkah demi langkah tentang cara menyambungkan ke basis data Amazon Aurora Anda tersedia dalam Panduan Konektivitas Amazon Aurora.

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

Ya, Aurora edisi kompatibel PostgreSQL dan MySQL memenuhi syarat HIPAA, sehingga Anda dapat menggunakannya untuk membangun aplikasi yang patuh HIPAA dan menyimpan informasi yang berhubungan dengan pemeliharaan kesehatan, termasuk informasi kesehatan yang dilindungi (PHI) di bawah Perjanjian Rekan Bisnis (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. Untuk informasi selengkapnya tentang membangun aplikasi yang memenuhi syarat di AWS, lihat Penyedia & Penjamin Layanan Kesehatan di Cloud.

P: Di mana saya dapat mengakses daftar entri Common Vulnerabilities and Exposures (CVE) untuk kerentanan keamanan dunia maya yang dikenal secara umum untuk rilis Amazon Aurora?

Saat ini Anda dapat menemukan daftar CVE di Amazon Aurora Security Updates.

Tanpa Server

T: Apa itu Amazon Aurora Serverless?

Amazon Aurora Serverless adalah konfigurasi penskalaan otomatis sesuai permintaan yang secara otomatis menyesuaikan kapasitas basis data menurut kebutuhan aplikasi. Dengan Aurora Nirserver, Anda cukup membayar kapasitas basis data, penyimpanan, dan I/O yang digunakan basis data Anda saat aktif. Kapasitas basis data Anda secara otomatis menaik-turunkan skala untuk memenuhi workload aplikasi Anda dan mati selama periode tidak aktif, menghemat uang dan waktu administrasi Anda. Aurora Serverless mengukur kapasitas basis data dalam Aurora Capacity Units (ACU) yang ditagih per detik. Satu ACU memiliki sekitar 2 GB memori yang setara dengan CPU dan jaringan, sama dengan yang digunakan pada instans yang disediakan Aurora.

Aurora Serverless v2, saat ini dalam mode pratinjau, langsung menskalakan basis data untuk mendukung ratusan ribu transaksi per detik dan mendukung semua fitur Aurora termasuk deployment Multi-AZ, Replika Baca, dan Basis Data Global. Ini cocok untuk semua jenis beban kerja basis data relasional, hingga dan termasuk aplikasi penting bisnis yang paling menuntut.

Amazon Aurora Serverless v1 menjadi opsi sederhana dan hemat biaya untuk beban kerja yang tidak terlalu sering, sesekali, atau tak terduga.

T: Versi Amazon Aurora mana yang didukung Aurora Serverless?

Aurora Serverless v1 saat ini tersedia untuk Aurora dengan kompatibilitas MySQL 5.6 dan Aurora dengan kompatibilitas PostgreSQL 10.7+. Aurora Serverless v2 saat ini tersedia dalam pratinjau untuk Aurora Edisi Kompatibel MySQL.

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

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 Serverless?

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

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

Sementara Aurora Serverless melakukan penskalaan 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 jumlah besar. Dalam kasus ini, Anda dapat mengatur kapasitas secara eksplisit hingga nilai tertentu dengan Konsol Manajemen AWS, AWS CLI, atau API Amazon RDS.

T: Mengapa Klaster DB Aurora Serverless saya tidak diskalakan secara otomatis?

Setelah operasi penskalaan dimulai, Aurora Nirserver mencoba untuk menemukan titik penskalaan, yang merupakan titik di mana basis data dapat diskalakan penuh dengan aman. Aurora Nirserver 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 Serverless, kapasitas basis data diukur dalam Unit Kapasitas Aurora (ACU). Anda cukup membayar harga tetap per detik penggunaan ACU, dengan minimal lima menit penggunaan setiap kali basis data diaktifkan. Harga penyimpanan dan I/O sama dengan konfigurasi yang disediakan dan Serverless. 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?

Parallel Query menghasilkan performa lebih cepat, meningkatkan kecepatan kueri analisis sebesar dua urutan magnitudo. Ini juga memberikan kesederhanaan operasional dan kesegaran data karena Anda dapat mengeluarkan kueri secara langsung atas data transaksional saat ini dalam klaster Aurora Anda. Dan, Parallel Query memungkinkan beban kerja transaksional dan analisis pada basis data yang sama dengan 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 Parallel Query 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.

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, I/O, dan penyimpanan.

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

Tidak, I/O karena Parallel Query mengurangi biaya I/O 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 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, eksekusi berturut-turut atas kueri Parallel Query yang sama akan menimbulkan biaya I/O penuh.

T: Versi Amazon Aurora mana yang mendukung Parallel Query?

Parallel Query tersedia untuk versi Amazon Aurora yang kompatibel dengan MySQL 5.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 performa yang jarang, haruskah saya mengaktifkannya sepanjang waktu?

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

T: Dapatkah Aurora 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 basis data relasional, dan cocok untuk kasus penggunaan seperti analisis operasional, ketika Anda perlu melakukan kueri analisis cepat pada data segar dalam basis data Anda.

Amazon DevOps Guru for RDS

T: Apa yang dimaksud Amazon DevOps Guru untuk RDS?

Amazon DevOps Guru untuk RDS adalah kemampuan yang didukung ML baru untuk Amazon RDS yang dirancang untuk 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 jenis 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 berlebih, dan kesalahan kueri SQL tertentu). Ketika terjadi masalah, Amazon DevOps Guru untuk RDS dirancang untuk segera memberitahu developer dan teknisi DevOps serta menyediakan informasi diagnostik, rincian besarnya masalah, dan rekomendasi perbaikan cerdas untuk membantu pelanggan dengan cepat menyelesaikan hambatan performa dan masalah operasional terkait basis data.

T: Mengapa saya sebaiknya menggunakan DevOps Guru untuk RDS?

Amazon DevOps Guru untuk RDS dirancang untuk menghapus upaya manual dan mempersingkat waktu (dari jam dan hari ke menit) untuk mendeteksi dan menyelesaikan hambatan performa yang sulit ditemukan dalam beban kerja basis data relasional Anda. Anda dapat mengaktifkan DevOps Guru untuk RDS untuk setiap basis data Amazon Aurora, dan ia akan otomatis mendeteksi masalah performa untuk beban kerja Anda, mengirimkan pemberitahuan kepada Anda untuk setiap masalah, menjelaskan temuan, dan merekomendasikan tindakan untuk menyelesaikannya. DevOps Guru untuk RDS membantu menjadikan administrasi basis data lebih mudah diakses bagi nonahli dan membantu para ahli basis data agar mereka dapat mengelola lebih banyak basis data.

T: Bagaimana cara kerja Amazon DevOps Guru untuk RDS?

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

T: Bagaimana cara memulai dengan Amazon DevOps Guru untuk RDS?

Untuk memulai dengan DevOps Guru untuk RDS, pastikan Wawasan Kinerja diaktifkan melalui konsol RDS, dan lalu aktifkan saja DevOps Guru untuk basis data Amazon Aurora Anda. Dengan DevOps Guru, Anda dapat memilih batasan cakupan analisis Anda menjadi keseluruhan akun AWS Anda, menentukan tumpukan AWS CloudFormation spesifik yang ingin dianalisis oleh DevOps Guru, atau menggunakan tanda AWS untuk membuat grup sumber daya yang ingin dianalisis oleh DevOps Guru.

T: Jenis masalah apa yang dapat dideteksi Amazon DevOps Guru untuk RDS?

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

T: Apa yang membedakan DevOps Guru untuk RDS dari Wawasan Kinerja Amazon RDS?

Wawasan Kinerja Amazon RDS adalah fitur penyetelan dan pemantauan kinerja basis data yang mengumpulkan dan memvisualisasikan metrik performa basis data Amazon RDS, membantu Anda dengan cepat mengukur muatan di basis data Anda, dan menentukan kapan dan di mana mengambil tindakan. Amazon DevOps Guru untuk RDS dirancang untuk memantau metrik-metrik tersebut, mendeteksi ketika basis data Anda mengalami masalah performa, menganalisis metrik, kemudian memberitahu Anda apa yang salah dan apa yang dapat Anda lakukan.

Pelajari selengkapnya tentang harga Amazon Aurora

Kunjungi halaman harga
membuat to build.
Memulai Amazon Aurora
Punya pertanyaan lainnya?
Hubungi kami