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

Aurora memiliki sistem penyimpanan terdistribusi, yang toleran terhadap kesalahan serta dapat melakukan pemulihan mandiri yang dipisahkan dari sumber daya komputasi dan secara otomatis menaikkan skala hingga 128 TiB per instans basis data. Aurora memberikan performa dan ketersediaan tinggi dengan hingga 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 memakan banyak waktu seperti penyediaan perangkat keras, penyiapan basis data, patching, dan pencadangan sekaligus menyediakan keamanan, ketersediaan, dan keandalan basis data komersial dengan biaya hanya sepersepuluhnya.

Amazon Aurora sepenuhnya kompatibel dengan basis data sumber terbuka MySQL yang sudah ada dan menambah dukungan untuk rilis baru secara berkala. Dengan demikian, Anda dapat dengan mudah memindahkan basis data MySQL ke dan dari Aurora menggunakan alat atau snapshot impor/ekspor standar. Hal tersebut juga membuat 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, hubungi Dukungan AWS. Jika Anda memiliki akun AWS Premium Support yang aktif, Anda dapat menghubungi AWS Premium Support untuk masalah khusus 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 panduan dan sumber daya mendetail, buka halaman Memulai menggunakan Aurora kami.

Anda dapat melihat ketersediaan Wilayah untuk Aurora di sini.

Jika Anda ingin bermigrasi dari MySQL ke 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 Aurora, begitu pula sebaliknya.
• Anda juga dapat menggunakan fitur migrasi Snapshot DB Amazon RDS untuk memigrasikan Snapshot DB Amazon RDS for MySQL ke Aurora menggunakan Konsol Manajemen AWS.

Bagi sebagian besar pelanggan, migrasi ke Aurora selesai dalam waktu kurang dari satu jam, meskipun durasi tersebut bergantung pada format dan ukuran set data. Untuk informasi selengkapnya, lihat Praktik Terbaik untuk Memigrasi Basis Data MySQL ke Amazon Aurora.

Jika Anda ingin bermigrasi dari PostgreSQL ke 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 Aurora, begitu pula sebaliknya.
• Anda juga dapat menggunakan fitur migrasi Snapshot DB RDS untuk memigrasikan Snapshot DB Amazon RDS for PostgreSQL ke Aurora menggunakan Konsol Manajemen AWS.

Bagi sebagian besar pelanggan, migrasi ke Aurora selesai dalam waktu kurang dari satu jam, meskipun durasi tersebut bergantung pada format dan ukuran set data.

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

Tidak, Aurora dapat berfungsi 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, sebaiknya bangun aplikasi untuk mendorong kueri dan transaksi konkuren dalam jumlah besar.

Lihat halaman harga Aurora untuk informasi harga saat ini.

Saat ini tidak ada penawaran AWS Tingkat Gratis untuk Aurora. Meskipun demikian, Aurora menyimpan data Anda secara tahan lama di tiga Zona Ketersediaan di satu Wilayah dan mengenakan biaya hanya untuk satu salinan data. Anda tidak dikenai biaya untuk pencadangan hingga 100% ukuran klaster basis data. Anda juga tidak dikenai biaya untuk snapshot selama periode retensi cadangan yang telah Anda konfigurasi untuk klaster basis data.

Tidak, replikasi Aurora sudah termasuk dalam harga tersebut. Anda akan dikenai biaya berdasarkan penyimpanan yang digunakan basis data Anda pada lapisan basis data, tidak penyimpanan yang digunakan dalam lapisan penyimpanan virtual Aurora.

Operasi I/O dijalankan oleh mesin basis data Aurora pada lapisan penyimpanan virtual berbasis SSD. Setiap operasi baca halaman basis data akan 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 dikenai biaya saat mengambil halaman data apa pun dari memori.
• Jika lalu lintas kueri Anda tidak dapat dilayani sepenuhnya dari memori, Anda akan dikenai biaya untuk setiap halaman data yang perlu diambil dari penyimpanan.
  Setiap halaman basis data memiliki ukuran 16 KB dalam Amazon Aurora Edisi yang Kompatibel dengan MySQL dan 8 KB dalam Aurora Edisi yang Kompatibel dengan PostgreSQL.

Aurora didesain untuk menghapus operasi I/O yang tidak diperlukan agar dapat mengurangi biaya serta memastikan sumber daya tersedia untuk memberikan lalu lintas baca/tulis. Operasi I/O tulis hanya digunakan ketika mempertahankan catatan log pengulangan (redo) di Aurora Edisi yang Kompatibel dengan MySQL atau catatan log tulis di depan (write ahead) di Aurora Edisi yang Kompatibel dengan PostgreSQL ke lapisan penyimpanan dengan tujuan agar penulisan bertahan lama.

Operasi I/O tulis dihitung dalam satuan 4 KB. Contohnya, catatan log yang berukuran 1,024 bita akan dihitung sebagai satu operasi I/O tulis. Namun, jika catatan log berukuran lebih besar dari 4 KB, lebih dari satu operasi I/O tulis akan diperlukan untuk mempertahankannya.

Operasi tulis secara bersamaan yang memiliki catatan log kurang dari 4 KB dapat dibuat batch oleh mesin basis data Aurora untuk mengoptimalkan penggunaan I/O. Tidak seperti mesin basis data tradisional, Aurora tidak akan mendorong halaman data kotor ke penyimpanan.

Anda dapat melihat jumlah permintaan I/O yang digunakan oleh instans Aurora Anda dengan memeriksa 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 “VolumeReadIOPs” dan “VolumeWriteIOPs” di bagian pemantauan.

Untuk informasi selengkapnya tentang harga operasi I/O, kunjungi halaman harga Aurora. Anda dikenai biaya untuk operasi I/O baca dan tulis jika mengonfigurasi klaster basis data ke konfigurasi Aurora Standar. Anda tidak dikenai biaya untuk operasi I/O baca dan tulis jika mengonfigurasi klaster basis data untuk Amazon Aurora I/O Dioptimalkan.

Aurora menawarkan fleksibilitas untuk mengoptimalkan pengeluaran basis data Anda dengan memilih antara dua opsi konfigurasi berdasarkan kebutuhan performa harga dan prediksi harga Anda. Kedua opsi konfigurasi tersebut adalah Aurora Standar dan Aurora I/O Dioptimalkan. Keduanya tidak memerlukan I/O atau penyediaan penyimpanan di muka. Keduanya dapat menskalakan operasi I/O untuk mendukung aplikasi yang memiliki kebutuhan tinggi.

Aurora Standar adalah konfigurasi klaster basis data yang menawarkan harga hemat biaya untuk sebagian besar aplikasi dengan penggunaan I/O rendah hingga sedang. Dengan Aurora Standar, Anda membayar instans basis data, penyimpanan, dan I/O bayar per permintaan.

Aurora I/O Dioptimalkan adalah konfigurasi klaster basis data yang memberikan peningkatan performa harga untuk aplikasi intensif I/O seperti sistem pemrosesan pembayaran, sistem e-commerce, dan aplikasi keuangan. Selain itu, jika pengeluaran I/O melebihi 25% dari total pengeluaran basis data Aurora, Anda dapat menghemat hingga 40% untuk biaya beban kerja intensif I/O dengan Aurora I/O Dioptimalkan. Aurora I/O Dioptimalkan menawarkan harga yang dapat diprediksi untuk semua aplikasi karena tidak ada biaya untuk operasi I/O baca dan tulis, sehingga konfigurasi ini cocok untuk beban kerja dengan variabilitas I/O yang tinggi.

Aurora I/O Dioptimalkan adalah pilihan ideal jika Anda membutuhkan biaya yang dapat diprediksi untuk aplikasi apa pun. Opsi ini memberikan peningkatan performa harga untuk aplikasi intensif I/O, yang memerlukan throughput tulis tinggi atau menjalankan kueri analitik yang memproses data dalam jumlah besar. Untuk pelanggan yang memiliki pengeluaran I/O melebihi 25% dari tagihan Aurora, Anda dapat menghemat hingga 40% untuk biaya beban kerja intensif I/O dengan Aurora I/O Dioptimalkan.

Anda dapat menggunakan pengalaman sekali klik yang tersedia di Konsol Manajemen AWS untuk mengubah jenis penyimpanan klaster basis data yang sudah ada menjadi Aurora I/O Dioptimalkan. Anda juga dapat menginvokasi AWS Command Line Interface (AWS CLI) atau AWS SDK untuk melakukan perubahan ini.

Anda dapat mengganti klaster basis data yang sudah ada setiap 30 hari sekali ke Aurora I/O Dioptimalkan. Anda dapat beralih kembali ke Aurora Standar sewaktu-waktu.

Ya, Aurora I/O Dioptimalkan dapat berjalan dengan Instans Terpesan Aurora yang sudah ada. Aurora secara otomatis menghitung perbedaan harga antara Aurora Standar dan Aurora I/O Dioptimalkan dengan Instans Terpesan. Dengan diskon Instans Terpesan dan Aurora I/O Dioptimalkan, Anda dapat memperoleh lebih banyak penghematan pada pengeluaran I/O.

Tidak ada perubahan pada harga backtrack, snapshot, ekspor, atau pencadangan berkelanjutan dengan Aurora I/O Dioptimalkan.

Ya, biaya untuk operasi I/O yang diperlukan untuk mereplikasi data di seluruh Wilayah akan terus berlaku. Aurora I/O Dioptimalkan tidak mengenakan biaya untuk operasi I/O baca dan tulis, berbeda dari replikasi data.

Tidak ada biaya tambahan untuk Amazon Aurora Optimized Reads untuk Aurora PostgreSQL selain harga instans R6id berbasis Intel dan R6gd berbasis Graviton. Untuk informasi selengkapnya, kunjungi halaman harga Aurora.

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. Perhatikan 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 menjadikan data Anda tahan lama di tiga Zona Ketersediaan (AZ) dalam suatu Wilayah dan akan secara otomatis mencoba untuk memulihkan basis data dalam AZ yang memiliki kondisi baik tanpa kehilangan data. Seandainya data tidak tersedia dalam penyimpanan Amazon Aurora, Anda dapat melakukan pemulihan dari Snapshot DB atau melakukan operasi pemulihan titik waktu 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 tentang 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 terenkripsi.

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 Aurora dalam AZ yang sama atau berbeda, saat failover terjadi, Aurora akan membalikkan catatan nama kanonik (CNAME) untuk Instans DB Anda guna menunjuk replika yang berkondisi baik, yang dipromosikan menjadi primer baru. Dari awal hingga akhir, failover biasanya selesai dalam waktu 30 detik. Untuk ketahanan yang ditingkatkan dan failover yang lebih cepat, pertimbangkan untuk menggunakan Proksi Amazon RDS yang secara otomatis terhubung ke instans DB failover sekaligus mempertahankan koneksi aplikasi. Proksi membuat failover menjadi transparan bagi aplikasi Anda dan mengurangi waktu failover hingga 66%.
• Jika Anda menjalankan Aurora Nirserver v1 dan instans DB atau AZ menjadi tidak tersedia, Aurora akan secara otomatis membuat ulang instans DB dalam AZ yang berbeda. Aurora Nirserver v2 berfungsi seperti disediakan untuk failover dan fitur ketersediaan tinggi lainnya. Untuk informasi selengkapnya, lihat Aurora Nirserver v2 dan ketersediaan tinggi.. 
• Jika Anda tidak memiliki Replika Aurora (yaitu instans tunggal) dan tidak sedang menjalankan Aurora Nirserver, Aurora akan mencoba untuk membuat Instans DB baru dalam Zona Ketersediaan yang sama dengan instans asli. Penggantian instans asli ini dilakukan dengan usaha terbaik dan memiliki kemungkinan untuk tidak berhasil, misalnya jika terjadi masalah yang secara luas memengaruhi Zona Ketersediaan.
  

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.

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.

Basis data Aurora harus diakses 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 terhubung ke basis data Amazon Aurora Anda tersedia dalam Panduan Konektivitas Amazon Aurora.

Ya, Aurora edisi yang kompatibel dengan MySQL dan PostgreSQL memenuhi syarat HIPAA. Anda dapat menggunakannya untuk membangun aplikasi yang patuh terhadap HIPAA dan menyimpan informasi terkait layanan kesehatan, termasuk informasi kesehatan yang dilindungi (PHI) di bawah Business Associate Addendum (BAA) yang disetujui bersama AWS. Jika Anda telah membuat perjanjian BAA dengan AWS, tidak ada tindakan lebih lanjut yang diperlukan untuk mulai menggunakan layanan ini di akun yang dicakup oleh BAA Anda. Untuk informasi selengkapnya tentang penggunaan AWS untuk membangun aplikasi yang patuh, lihat Penyedia Layanan Kesehatan.

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

Aurora terintegrasi dengan Amazon GuardDuty untuk membantu mengidentifikasi potensi ancaman terhadap data yang disimpan dalam basis data Aurora. Perlindungan RDS GuardDuty membuat profil dan memantau aktivitas masuk serta basis data baru di akun Anda, dan menggunakan model ML yang disesuaikan untuk mendeteksi aktivitas masuk yang mencurigakan ke basis data Aurora. Untuk informasi selengkapnya, lihat Memantau ancaman dengan Perlindungan RDS GuardDuty dan Panduan Pengguna Perlindungan RDS GuardDuty.

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

Anda akan membayar kapasitas basis data yang Anda gunakan dengan basis per detik saat basis data aktif. Pelajari selengkapnya tentang Aurora Nirserver dan mulai dengan beberapa langkah 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 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. Hasilnya, Aurora Nirserver v2 tetap dapat menskalakan meskipun terdapat transaksi yang sangat lama, penguncian tabel, dan hal lainnya.

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

Aurora Nirserver v1 merupakan opsi yang sederhana dan hemat biaya untuk beban kerja yang jarang, intermiten, 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 tersedia, termasuk replika baca, konfigurasi Multi-AZ, Basis Data Global Aurora, Proksi 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.

Di Aurora Nirserver, kapasitas basis data diukur dalam ACU. Anda akan membayar tarif tetap atas penggunaan ACU per detik. Biaya komputasi untuk menjalankan beban kerja di Aurora Nirserver akan bergantung pada konfigurasi klaster basis data yang Anda pilih: Aurora Standar atau Aurora I/O Dioptimalkan. Kunjungi halaman harga Aurora untuk informasi tentang harga dan ketersediaan Wilayah.

Amazon Aurora Optimized Reads yang tersedia untuk Aurora PostgreSQL adalah opsi performa harga baru yang memberikan latensi kueri hingga 8x lebih baik dan penghematan biaya hingga 30% dibandingkan dengan instans tanpa kemampuan ini. Kemampuan ini sangat ideal untuk aplikasi dengan set data besar yang melebihi kapasitas memori instans basis data.

Instans Amazon Aurora Optimized Reads menggunakan penyimpanan tingkat blok SSD berbasis NVMe lokal (tersedia pada instans r6gd berbasis Graviton dan r6id berbasis Intel) untuk meningkatkan latensi kueri aplikasi dengan set data melebihi kapasitas memori instans basis data. Optimized Reads mencakup peningkatan performa seperti caching berjenjang dan objek sementara.

Caching berjenjang memberikan peningkatan latensi kueri hingga 8x dan penghematan biaya hingga 30% untuk aplikasi yang banyak membaca dan intensif I/O seperti dasbor operasional, deteksi anomali, dan pencarian kesamaan berbasis vektor. Manfaat ini diwujudkan dengan secara otomatis membuat cache data yang dikeluarkan dari cache buffer basis data dalam memori ke penyimpanan lokal untuk mempercepat akses selanjutnya atas data tersebut. Caching berjenjang hanya tersedia untuk Amazon Aurora PostgreSQL Edition dengan konfigurasi Aurora I/O Dioptimalkan.

Objek sementara mencapai pemrosesan kueri yang lebih cepat dengan menempatkan tabel sementara yang dihasilkan oleh Aurora PostgreSQL pada penyimpanan lokal, meningkatkan performa kueri yang melibatkan pengurutan, agregasi hash, gabungan beban tinggi, dan operasi intensif data lainnya.

Amazon Aurora Optimized Reads untuk Aurora PostgreSQL menawarkan kepada pelanggan, dengan aplikasi sensitif latensi dan set kerja besar, alternatif performa harga yang menarik untuk memenuhi SLA bisnis mereka dan melakukan lebih banyak lagi dengan instans mereka.

Amazon Aurora Optimized Reads tersedia pada instans R6id berbasis Intel dan R6gd berbasis Graviton. Anda dapat melihat ketersediaan Wilayah untuk Aurora di sini.

Amazon Aurora Optimized Reads tersedia untuk Aurora Edisi Kompatibel PostgreSQL pada instans R6id dan R6gd. Versi mesin yang didukung adalah 15.4 dan lebih tinggi dan 14.9 dan lebih tinggi pada Aurora PostgreSQL.

Amazon Aurora Optimized Reads tidak tersedia di Aurora Nirserver v2 (ASv2).

Ya, Amazon Aurora Optimized Reads tersedia dengan kedua konfigurasi tersebut. Pada kedua konfigurasi tersebut, instans dengan dukungan Optimized Reads secara otomatis memetakan tabel sementara ke penyimpanan lokal berbasis NVMe untuk meningkatkan performa kueri analitik dan pembuatan ulang indeks.

Untuk beban kerja intensif I/O yang berat dalam membaca, instans dengan dukungan Optimized Reads pada Aurora PostgreSQL yang dikonfigurasi untuk menggunakan Aurora I/O Dioptimalkan secara otomatis membuat cache data yang dikeluarkan dari memori pada penyimpanan lokal berbasis NVMe untuk menghasilkan latensi kueri yang ditingkatkan hingga 8x dan penghematan biaya hingga 30% dibandingkan dengan instans tanpa kemampuan ini, untuk aplikasi dengan set data besar yang melebihi kapasitas memori instans basis data.

Pelanggan dapat memulai dengan Amazon Aurora Optimized Reads melalui Konsol Manajemen AWS, CLI, dan SDK. Optimized Reads tersedia pada semua instans R6id dan R6gd secara default. Untuk menggunakan kemampuan ini, pelanggan cukup memodifikasi klaster basis data Aurora yang ada untuk menyertakan instans R6id dan R6gd, atau membuat klaster basis data baru menggunakan instans ini. Lihat dokumentasi Amazon Aurora Optimized Reads untuk memulai.

Sekitar 90% penyimpanan lokal yang tersedia pada instans R6id dan R6gd tersedia untuk Optimized Reads, Aurora mencadangkan 10% dari penyimpanan NVMe untuk mengurangi dampak amplifikasi tulis SSD. Alokasi penyimpanan yang tersedia tergantung pada fitur Optimized Reads yang diaktifkan.

Saat menggunakan Optimized Reads dengan fitur Objek Sementara dan Caching Berjenjang, ruang yang tersedia untuk objek sementara di penyimpanan lokal setara dengan 2x ukuran memori yang tersedia pada instans basis data ini. Ini cocok dengan ukuran penyimpanan objek sementara saat ini di Aurora PostgreSQL. Ruang disk penyimpanan lokal yang tersisa tersedia untuk caching data.

Saat menggunakan Optimized Reads hanya dengan fitur Objek Sementara, semua ruang disk penyimpanan lokal yang tersedia akan tersedia untuk objek sementara. Misalnya, saat menggunakan instans r6gd.8xlarge dengan fitur Objek Sementara dan Caching Berjenjang, 534 GiB (kapasitas memori 2x) dicadangkan untuk objek sementara, dan 1054 GiB untuk cache berjenjang.

Jika penyimpanan lokal gagal, Aurora secara otomatis melakukan penggantian host. Dalam klaster basis data multi-simpul, ini memicu failover dalam wilayah.

Jika terjadi failover basis data, latensi kueri akan meningkat sementara setelah failover. Peningkatan latensi ini akan berkurang seiring waktu dan akhirnya mengejar latensi kueri sebelum failover. Durasi pengejaran ini dapat dipercepat dengan mengaktifkan manajemen cache klaster (CCM). Dengan CCM, pelanggan dapat menentukan instans basis data Aurora PostgreSQL tertentu sebagai target failover.

Ketika CCM diaktifkan, cache penyimpanan lokal dari target failover yang ditentukan mencerminkan cache penyimpanan lokal dari instans utama, sehingga mengurangi waktu pemulihan setelah failover. Namun, mengaktifkan CCM dapat berdampak pada efektivitas jangka panjang cache penyimpanan lokal jika target failover yang ditentukan juga digunakan untuk melayani beban kerja baca yang terpisah dari beban kerja pada instans penulis.

Oleh karena itu, pelanggan yang menjalankan beban kerja yang memerlukan pembaca ditetapkan sebagai failover siaga harus memungkinkan CCM meningkatkan kemungkinannya untuk segera mendapatkan kembali latensi kueri setelah failover. Pelanggan yang menjalankan beban kerja terpisah pada target failover yang ditentukan mungkin ingin menyeimbangkan kebutuhan mereka akan pemulihan latensi segera setelah failover dengan efektivitas performa cache jangka panjang, sebelum mengaktifkan CCM.

pgvector adalah ekstensi sumber terbuka untuk PostgreSQL yang didukung oleh Amazon Aurora Edisi yang Kompatibel dengan PostgreSQL.

Ya. Machine learning (ML) Aurora mengekspos model ML sebagai fungsi SQL, sehingga memungkinkan Anda menggunakan SQL standar guna memanggil model ML, meneruskan data ke model tersebut, dan mengembalikan prediksi sebagai hasil kueri. pgvector membutuhkan penyematan vektor untuk disimpan dalam basis data yang mengharuskan menjalankan model ML pada teks sumber atau data gambar untuk menghasilkan penyematan, lalu memindahkan penyematan dalam batch ke Aurora PostgreSQL.

ML Aurora dapat menjadikannya proses waktu nyata yang memungkinkan penyematan tetap terbaru di Aurora PostgreSQL dengan melakukan panggilan berkala ke Amazon Bedrock atau Amazon SageMaker yang mengembalikan penyematan yang paling baru dari model Anda.

Ya. Ada dua metode untuk mengintegrasikan basis data Amazon Aurora dengan Amazon Bedrock untuk mendukung aplikasi AI generatif. Pertama, Amazon Aurora ML sekarang menyediakan akses ke model dasar yang tersedia di Amazon Bedrock langsung melalui SQL untuk Aurora MySQL dan Aurora PostgreSQL. Kedua, Anda dapat mengonfigurasi Aurora sebagai Basis Pengetahuan untuk Amazon Bedrock dan menyimpan penyematan yang dihasilkan dari Bedrock di Aurora. Basis Pengetahuan untuk Amazon Bedrock mendukung Aurora PostgreSQL sebagai penyimpanan vektor untuk kasus penggunaan seperti Retrieval Augmented Generation (RAG). Baca blog dan dokumentasi kami tentang cara menggunakan Aurora PostgreSQL sebagai Basis Pengetahuan untuk Amazon Bedrock.

Amazon Aurora PostgreSQL Optimized Reads dengan pgvector meningkatkan kueri per detik untuk pencarian vektor hingga 9x dalam beban kerja yang melebihi memori instans yang tersedia. Hal ini dimungkinkan karena kemampuan caching berjenjang yang tersedia dalam Optimized Reads yang secara otomatis melakukan cache data yang dikeluarkan dari cache buffer basis data dalam memori ke penyimpanan lokal untuk mempercepat akses selanjutnya atas data tersebut.

Baca blog dan dokumentasi kami tentang cara meningkatkan kinerja kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads.

Anda harus menggunakan integrasi nol-ETL Amazon Aurora dengan Amazon Redshift ketika membutuhkan akses mendekati waktu nyata ke data transaksional. Integrasi ini memungkinkan Anda untuk memanfaatkan ML Amazon Redshift dengan perintah SQL langsung.

Integrasi nol-ETL Aurora dengan Amazon Redshift tersedia di Aurora Edisi Kompatibel MySQL untuk Aurora MySQL versi 3.05 (kompatibel dengan MySQL 8.0.32) dan yang lebih tinggi di Wilayah AS Timur (Ohio), AS Timur (Virginia Utara), AS Barat (Oregon), Asia Pasifik (Singapura), Asia Pasifik (Sydney), Asia Pasifik (Tokyo), Eropa (Frankfurt), Eropa (Irlandia), dan Eropa (Stockholm). Integrasi nol-ETL Aurora dengan Amazon Redshift tersedia di Aurora Edisi Kompatibel PostgreSQL untuk Aurora PostgreSQL 15.4 di Wilayah AS Timur (Ohio).

Integrasi nol-ETL Aurora dengan Amazon Redshift menghilangkan kebutuhan untuk membangun dan memelihara jalur data yang kompleks. Anda dapat mengonsolidasikan data dari beberapa tabel dari berbagai klaster basis data Aurora ke satu klaster basis data Amazon Redshift dan menjalankan analitik serta ML mendekati waktu nyata menggunakan Amazon Redshift pada petabita data transaksional dari Aurora. Anda dapat memilih basis data dan tabel yang akan direplikasi dari Aurora ke Amazon Redshift. Berdasarkan kebutuhan analitik Anda, pemfilteran data basis data dan tabel tertentu membantu Anda memasukkan data ke Amazon Redshift secara selektif.

Integrasi nol-ETL Aurora dengan Amazon Redshift kompatibel dengan Aurora Nirserver v2. Saat menggunakan Aurora Nirserver v2 dan Amazon Redshift Nirserver, Anda dapat menghasilkan analitik mendekati waktu nyata pada data transaksional tanpa harus mengelola infrastruktur apa pun untuk jalur data.

Anda dapat mulai menggunakan konsol Amazon RDS untuk membuat integrasi nol-ETL dengan menentukan sumber Aurora dan tujuan Amazon Redshift. Setelah integrasi dibuat, basis data Aurora akan direplikasi ke Amazon Redshift dan Anda dapat mulai mengueri data setelah penempatan awal selesai. Untuk informasi selengkapnya, baca panduan memulai untuk integrasi nol-ETL Aurora dengan Amazon Redshift.

Pemrosesan perubahan data yang berkelanjutan dengan integrasi nol-ETL ditawarkan tanpa biaya tambahan. Anda membayar sumber daya Amazon RDS dan Amazon Redshift yang ada yang digunakan untuk membuat serta memproses data perubahan yang dihasilkan sebagai bagian dari integrasi nol-ETL. Sumber daya ini dapat mencakup:

• I/O dan penyimpanan tambahan yang digunakan dengan mengaktifkan binlog yang ditingkatkan
• Biaya eskpor snapshot untuk ekspor data awal guna menempatkan basis data Amazon Redshift Anda
• Penyimpanan Amazon Redshift tambahan untuk menyimpan data yang direplikasi
• Komputasi Amazon Redshift tambahan untuk memproses replikasi data
• Biaya transfer data lintas AZ untuk memindahkan data dari sumber ke target

Untuk informasi selengkapnya, kunjungi halaman harga Aurora.

Ya, Anda dapat mengelola dan mengotomatiskan konfigurasi dan deployment sumber daya yang diperlukan untuk integrasi nol-ETL Aurora MySQL dengan Amazon Redshift menggunakan AWS CloudFormation. Untuk informasi selengkapnya, kunjungi templat CloudFormation dengan integrasi nol-ETL.

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 didesain 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 dilakukan.

Anda harus menggunakan API untuk aplikasi modern baru, khususnya yang dibangun dengan AWS Lambda yang perlu mengakses Aurora dalam model permintaan/respons. Anda harus menggunakan driver basis data, bukan API Data, dan mengelola koneksi basis data yang persisten ketika aplikasi yang ada sangat terkait dengan driver basis data, ketika ada kueri yang berjalan lama, atau ketika developer ingin memanfaatkan fitur basis data seperti tabel sementara atau penggunaan variabel sesi.

Wilayah AWS API Data dan ketersediaan versi basis data untuk Aurora Nirserver v2 dan instans yang disediakan Aurora dapat ditemukan di dokumentasi kami. Pelanggan yang saat ini menggunakan API Data untuk Aurora Nirserver v1 didorong untuk bermigrasi ke Aurora Nirserver v2 untuk memanfaatkan API Data yang didesain ulang dan penskalaan Aurora Nirserver v2 yang lebih terperinci.

Data API akan memungkinkan Anda menyederhanakan dan mempercepat pengembangan aplikasi modern. API Data adalah API berbasis HTTP aman yang mudah digunakan yang menghilangkan kebutuhan untuk melakukan deployment driver basis data, mengelola kumpulan koneksi sisi klien, atau menyiapkan jaringan VPC yang kompleks antara aplikasi dan basis data. API Data juga meningkatkan skalabilitas dengan mengumpulkan dan berbagi koneksi basis data secara otomatis, sehingga mengurangi overhead komputasi dari aplikasi yang sering membuka dan menutup koneksi. 

API Data yang ada untuk Aurora Nirserver v1 akan tetap menjadi fitur Aurora Nirserver v1 untuk Edisi Kompatibel PostgreSQL dan Edisi Aurora yang Kompatibel dengan MySQL. API Data untuk Aurora Nirserver v2 dan instans yang disediakan Aurora tidak mendukung Aurora Nirserver v1. API Data untuk instans Aurora Nirserver v2 dan Aurora yang disediakan mendukung instans penulis Basis Data Global Aurora.

Pengguna dapat menginvokasi operasi API Data hanya jika mereka diberi wewenang untuk melakukannya. Administrator dapat memberikan izin kepada pengguna untuk menggunakan API Data dengan melampirkan kebijakan AWS Identity and Access Management (IAM) yang menentukan hak istimewa mereka. Anda juga dapat melampirkan kebijakan ke suatu peran jika Anda menggunakan peran IAM. Saat Anda memanggil API Data, Anda dapat meneruskan kredensial untuk klaster DB Aurora dengan menggunakan rahasia di AWS Secrets Manager. 

Penggunaan API data dengan Aurora Nirserver v1 tetap tersedia tanpa biaya tambahan. API Data untuk instans Aurora Nirserver v2 dan Aurora yang disediakan diberi harga berdasarkan volume permintaan API seperti yang dijelaskan pada halaman harga Aurora. API Data untuk Aurora Nirserver v2 dan instans yang disediakan Aurora menggunakan peristiwa bidang data AWS CloudTrail untuk mencatat aktivitas, bukan peristiwa manajemen, seperti halnya dengan API Data untuk Aurora Nirserver v1.

Anda dapat mengaktifkan pencatatan peristiwa data melalui konsol CloudTrail, CLI, atau SDK jika Anda ingin melacak aktivitas ini. Hal ini akan dikenakan biaya sebagaimana ditetapkan pada halaman harga CloudTrail. Selain itu, penggunaan AWS Secrets Manager akan dikenakan biaya sebagaimana ditetapkan di halaman harga AWS Secrets Manager. 

AWS CloudTrail menangkap aktivitas API AWS sebagai peristiwa manajemen atau peristiwa data. Peristiwa manajemen CloudTrail (juga dikenal sebagai "operasi bidang kontrol") menunjukkan operasi manajemen yang dilakukan pada sumber daya di akun AWS Anda, seperti membuat, memperbarui, dan menghapus sumber daya. Peristiwa data CloudTrail (juga dikenal sebagai "operasi bidang data") menunjukkan operasi sumber daya yang dilakukan pada atau dalam sumber daya di akun AWS Anda.

API Data melakukan operasi bidang data karena melakukan kueri pada data dalam basis data Aurora Anda. Oleh karena itu, kami akan mencatat aktivitas API Data sebagai peristiwa data karena ini adalah kategorisasi peristiwa yang benar. Biaya hanya akan dikenakan untuk peristiwa data CloudTrail jika Anda mengaktifkan pencatatan peristiwa data.

Ya, tingkat gratis API Data mencakup satu juta permintaan per bulan, yang dikumpulkan di seluruh Wilayah AWS, untuk penggunaan tahun pertama. Setelah satu tahun, pelanggan akan mulai membayar API Data seperti yang dijelaskan di halaman harga Aurora.

Deployment Blue/Green Amazon RDS tersedia dalam Amazon Aurora MySQL-Compatible Edition versi 5.6 dan lebih tinggi serta Amazon Aurora PostgreSQL-Compatible Edition versi 11.21 dan lebih tinggi, 12.16 dan lebih tinggi, 13.12 dan lebih tinggi, 14.9 dan lebih tinggi, serta 15.4 dan lebih tinggi. Pelajari selengkapnya tentang versi yang tersedia di dokumentasi Aurora.

Deployment Blue/Green Amazon RDS tersedia di semua Wilayah AWS yang berlaku dan Wilayah AWS GovCloud.

Deployment Blue/Green Amazon RDS memungkinkan Anda melakukan perubahan basis data yang lebih aman, sederhana, dan cepat. Deployment Blue/Green ideal untuk kasus penggunaan, seperti peningkatan mesin basis data versi utama atau minor, pembaruan sistem operasi, perubahan skema pada lingkungan green yang tidak merusak replikasi logis, seperti menambahkan kolom baru di akhir tabel, atau perubahan pengaturan parameter basis data.

Anda dapat menggunakan Deployment Blue/Green untuk membuat beberapa pembaruan basis data secara bersamaan menggunakan satu switchover. Hal ini memungkinkan Anda untuk tetap mengikuti patch keamanan, meningkatkan performa basis data, serta mengakses fitur basis data yang lebih baru dengan waktu henti yang singkat dan dapat diprediksi. Jika Anda ingin melakukan peningkatan versi minor pada Aurora, sebaiknya gunakan Aurora Zero Downtime Patching (ZDP).

Anda akan dikenai biaya yang sama untuk menjalankan beban kerja Anda pada instans green seperti yang Anda lakukan untuk instans blue. Biaya menjalankan instans blue dan green mencakup harga standar kami saat ini untuk db.instances, biaya penyimpanan, biaya I/O baca/tulis, serta setiap fitur yang diaktifkan, seperti biaya pencadangan dan Wawasan Performa Amazon RDS. Anda akan membayar sekitar 2x biaya untuk menjalankan beban kerja di db.instance untuk masa pakai deployment-blue-green.

Misalnya: Anda memiliki klaster Aurora Edisi yang Kompatibel dengan MySQL 5.7 yang berjalan pada dua db.instances r5.2xlarge, instans penulis dan pembaca primer, di wilayah AWS us-east-1. Masing-masing db.instances r5.2xlarge dikonfigurasi untuk Penyimpanan 40 GiB dan memiliki 25 Juta I/O per bulan. Anda membuat kloning dari topologi instans blue menggunakan Deployment Blue/Green Amazon RDS, menjalankannya selama 15 hari (360 jam) dan setiap instans green memiliki 3 juta pembacaan I/O selama waktu tersebut. Anda kemudian menghapus instans blue setelah switchover berhasil. Instans blue (penulis dan pembaca) dikenai biaya sebesar 849,2 USD selama 15 hari dengan tingkat sesuai permintaan 1,179 USD/jam (Instans+Penyimpanan+I/O). Instans green (penulis dan pembaca) dikenai biaya sebesar 840,40 USD selama 15 hari dengan tingkat sesuai permintaan 1,167 USD/jam (Instans+Penyimpanan+I/O). Total biaya Anda untuk menggunakan Deployment Blue/Green selama 15 hari adalah 1689,60 USD, kira-kira 2x biaya untuk menjalankan instans blue untuk periode waktu tersebut.

Deployment Blue/Green Amazon RDS membantu Anda memungkinkan perubahan basis data yang lebih aman, sederhana, dan cepat, seperti peningkatan versi utama atau minor, perubahan skema, penskalaan instans, perubahan parameter mesin, serta pembaruan pemeliharaan.

Di Deployment Blue/Green Amazon RDS, lingkungan blue adalah lingkungan produksi Anda saat ini. Lingkungan green adalah lingkungan uji coba yang akan menjadi lingkungan produksi baru Anda setelah switchover.

Saat Deployment Blue/Green Amazon RDS memulai switchover, deployment tersebut akan memblokir penulisan ke lingkungan blue dan green hingga switchover selesai. Selama switchover, lingkungan uji coba, atau lingkungan green, akan mengikuti sistem produksi, sehingga memastikan data antara lingkungan uji coba dan produksi konsisten satu sama lain. Setelah lingkungan produksi dan uji coba disinkronkan sepenuhnya, Deployment Blue/Green mempromosikan lingkungan uji coba sebagai lingkungan produksi baru dengan mengarahkan lalu lintas ke lingkungan produksi yang baru dipromosikan.

Deployment Blue/Green Amazon RDS didesain untuk mengaktifkan penulisan di lingkungan green setelah switchover selesai, sehingga memastikan tidak ada kehilangan data selama proses switchover.

Deployment Blue/Green Amazon RDS tidak menghapus lingkungan produksi lama Anda. Jika diperlukan, Anda dapat mengaksesnya untuk validasi tambahan dan pengujian performa/regresi. Jika tidak lagi membutuhkan lingkungan produksi yang lama, Anda dapat menghapusnya. Biaya penagihan standar berlaku pada instans produksi lama hingga Anda menghapusnya.

Jika lingkungan blue Anda adalah replika logis yang dikelola sendiri, atau pelanggan, kami akan memblokir switchover. Sebaiknya hentikan replikasi ke lingkungan blue terlebih dahulu, proses switchover, lalu lanjutkan replikasi. Sebaliknya, jika lingkungan blue Anda adalah sumber untuk replika logis yang dikelola sendiri, atau penerbit, Anda dapat melanjutkan switchover. Namun, Anda perlu memperbarui replika yang dikelola sendiri untuk mereplikasi dari lingkungan green pasca-switchover.

Tidak, Deployment Blue/Green Amazon RDS tidak mendukung Basis Data Global Amazon Aurora, Proksi Amazon RDS, atau replika baca lintas Wilayah. 

Tidak, saat ini Anda tidak dapat menggunakan Deployment Blue/Green Amazon RDS untuk mengembalikan perubahan.

Ekstensi Bahasa Tepercaya (TLE) untuk PostgreSQL memungkinkan para developer untuk membangun ekstensi PostgreSQL beperforma tinggi dan menjalankannya dengan aman di Amazon Aurora. Dengan demikian, TLE akan meningkatkan waktu Anda untuk memasarkan dan menghilangkan beban yang ditempatkan pada administrator basis data untuk menyertifikasi kode kustom dan pihak ketiga untuk digunakan dalam beban kerja basis data produksi. Anda dapat melanjutkan segera setelah memutuskan bahwa ekstensi telah memenuhi kebutuhan Anda. Dengan TLE, vendor perangkat lunak independen (ISV) dapat menyediakan ekstensi PostgreSQL baru kepada pelanggan yang berjalan di Aurora.

TLE untuk PostgreSQL tersedia untuk Amazon Aurora Edisi yang Kompatibel dengan PostgreSQL pada versi 14.5 dan yang lebih tinggi. TLE diimplementasikan sebagai ekstensi PostgreSQL itu sendiri dan Anda dapat mengaktifkannya dari peran rds_superuser yang mirip dengan ekstensi lain yang didukung pada Aurora.

Anda dapat menjalankan TLE untuk PostgreSQL di PostgreSQL 14.5 atau lebih tinggi di Amazon Aurora.

Saat ini, TLE untuk PostgreSQL tersedia di semua Wilayah AWS (tidak termasuk Wilayah AWS Tiongkok) dan Wilayah AWS GovCloud.

TLE untuk PostgreSQL tersedia bagi pelanggan Aurora tanpa biaya tambahan.

Aurora dan Amazon RDS mendukung lebih dari 85 ekstensi PostgreSQL yang terkurasi. AWS mengelola risiko keamanan untuk masing-masing dari ekstensi ini di bawah model tanggung jawab bersama AWS. Ekstensi yang mengimplementasikan TLE untuk PostgreSQL disertakan dalam set ini. Ekstensi yang Anda tulis atau Anda peroleh dari sumber pihak ketiga dan diinstal di TLE akan dianggap sebagai bagian dari kode aplikasi Anda. Anda bertanggung jawab atas keamanan aplikasi yang menggunakan ekstensi TLE.

Anda dapat membangun fungsi developer, seperti kompresi bitmap dan privasi diferensial (seperti kueri statistik yang dapat diakses publik yang melindungi privasi individu).

Saat ini, TLE untuk PostgreSQL mendukung JavaScript, PL/pgSQL, Perl, dan SQL.

Setelah peran rds_superuser mengaktifkan TLE untuk PostgreSQL, Anda dapat melakukan deployment ekstensi TLE menggunakan perintah SQL CREATE EXTENSION dari klien PostgreSQL apa pun, seperti psql. Hal ini mirip dengan cara Anda membuat fungsi yang ditentukan pengguna yang ditulis dalam bahasa prosedural, seperti PL/pgSQL atau PL/Perl. Anda dapat mengontrol pengguna mana yang memiliki izin untuk melakukan deployment ekstensi TLE dan menggunakan ekstensi tertentu.

TLE untuk PostgreSQL mengakses basis data PostgreSQL Anda secara eksklusif melalui API TLE. Bahasa tepercaya yang didukung TLE mencakup semua fungsi antarmuka pemrograman server PostgreSQL (SPI) dan dukungan untuk hook PostgreSQL, termasuk hook periksa kata sandi.

Anda dapat mempelajari selengkapnya tentang TLE untuk proyek PostgreSQL di halaman GitHub TLE resmi.