Melakukan pembuktian konsep dengan Amazon Aurora

Dalam informasi berikut ini, Anda dapat menemukan penjelasan tentang cara menyiapkan dan menjalankan bukti konsep untuk Aurora. Pembuktian konsep adalah penyelidikan yang Anda lakukan untuk melihat apakah Aurora cocok dengan aplikasi Anda. Pembuktian konsep dapat membantu Anda memahami fitur Aurora dalam konteks aplikasi basis data Anda sendiri dan perbandingan Aurora dengan lingkungan basis data Anda saat ini. Ini juga dapat menunjukkan tingkat upaya apa yang Anda butuhkan untuk memindahkan data, SQL kode port, menyesuaikan kinerja, dan menyesuaikan prosedur manajemen Anda saat ini.

Dalam topik ini, Anda dapat menemukan ikhtisar dan step-by-step garis besar prosedur dan keputusan tingkat tinggi yang terlibat dalam menjalankan bukti konsep, tercantum berikut. Untuk petunjuk mendetail, Anda dapat membuka tautan ke dokumentasi lengkap untuk subjek spesifik.

Gambaran umum bukti konsep Aurora

Saat Anda melakukan bukti konsep untuk Amazon Aurora, Anda mempelajari apa yang diperlukan untuk mem-port data dan SQL aplikasi yang ada ke Aurora. Anda mencoba aspek penting Aurora dalam skala besar, menggunakan volume data dan aktivitas yang sesuai dengan lingkungan produksi Anda. Tujuannya adalah untuk menjadi yakin bahwa kecanggihan Aurora memang cocok untuk mengatasi tantangan yang menyebabkan Anda tidak dapat lagi mengandalkan infrastruktur basis data sebelumnya. Pada akhir pembuktian konsep, Anda akan memiliki rencana yang andal untuk melakukan penilaian tolok ukur performa dan pengujian aplikasi berskala lebih besar. Pada tahap ini, Anda memahami item pekerjaan terbesar dalam proses menuju deployment produksi.

Saran berikut tentang praktik terbaik dapat membantu Anda menghindari kesalahan umum yang dapat menyebabkan masalah selama proses penilaian tolok ukur. Namun, topik ini tidak mencakup step-by-step proses melakukan tolok ukur dan melakukan penyetelan kinerja. Prosedur tersebut bisa bervariasi, tergantung pada beban kerja Anda dan fitur Aurora yang Anda gunakan. Untuk informasi selengkapnya, baca dokumentasi yang terkait dengan performa seperti Mengelola performa dan penskalaan untuk klaster DB Aurora, Peningkatan performa Amazon Aurora MySQL, Kinerja dan penskalaan untuk Amazon Aurora Postgre SQL, dan Memantau beban DB dengan Performance Insights di Amazon Aurora.

Informasi dalam topik ini berlaku terutama untuk aplikasi di mana organisasi Anda menulis kode dan mendesain skema dan yang mendukung mesin database SQL sumber terbuka My SQL dan Postgre. Jika Anda menguji aplikasi komersial atau kode yang dihasilkan oleh kerangka kerja aplikasi, Anda mungkin tidak memiliki fleksibilitas untuk menerapkan semua pedoman. Dalam kasus seperti itu, tanyakan kepada AWS perwakilan Anda untuk melihat apakah ada praktik terbaik Aurora atau studi kasus untuk jenis aplikasi Anda.

1. Identifikasi tujuan Anda

Saat Anda mengevaluasi Aurora sebagai bagian dari pembuktian konsep, Anda perlu memilih jenis pengukuran apa yang akan dilakukan dan cara mengevaluasi keberhasilan percobaan ini.

Anda harus memastikan bahwa semua fungsionalitas aplikasi Anda kompatibel dengan Aurora. Karena versi utama Aurora kompatibel dengan kabel dengan versi utama My SQL dan Postgre yang sesuaiSQL, sebagian besar aplikasi yang dikembangkan untuk mesin tersebut juga kompatibel dengan Aurora. Meski demikian, Anda masih harus memvalidasi kompatibilitas per aplikasi.

Misalnya, beberapa pilihan konfigurasi yang Anda buat saat menyiapkan klaster Aurora akan memengaruhi apakah Anda bisa atau harus menggunakan fitur basis data tertentu. Anda dapat memulai dengan klaster Aurora yang paling umum, yang dikenal sebagai klaster terprovisi. Anda kemudian dapat memutuskan apakah konfigurasi khusus seperti kueri nirserver atau kueri paralel mampu memberi manfaat untuk menangani beban kerja Anda.

Gunakan pertanyaan-pertanyaan berikut untuk membantu mengidentifikasi dan mengukur tujuan Anda:

• Apakah Aurora mendukung semua kasus penggunaan fungsional beban kerja Anda?

• Berapa ukuran set data atau tingkat beban yang Anda inginkan? Bisakah Anda meningkatkan skala ke tingkat itu?

• Apa persyaratan latensi atau throughput kueri spesifik Anda? Bisakah Anda memenuhi persyaratannya?

• Berapa lama waktu henti minimum terencana atau tidak terencana yang Anda sanggupi untuk beban kerja Anda? Bisakah Anda mencapainya?

• Apa metrik yang diperlukan untuk meraih efisiensi operasional? Bisakah Anda memantaunya secara akurat?

• Apakah Aurora mendukung tujuan bisnis spesifik Anda, seperti pengurangan biaya, peningkatan deployment, atau kecepatan penyediaan? Apakah Anda memiliki cara untuk mengukur tujuan ini?

• Dapatkah Anda memenuhi semua persyaratan keamanan dan kepatuhan untuk beban kerja Anda?

Luangkan waktu untuk membangun pengetahuan tentang mesin basis data dan kemampuan platform Aurora, serta tinjau dokumentasi layanan ini. Catat semua fitur yang dapat membantu Anda mencapai hasil yang Anda inginkan. Salah satunya mungkin konsolidasi beban kerja, dijelaskan dalam posting Blog AWS Database Cara merencanakan dan mengoptimalkan Amazon Aurora dengan kompatibilitas SQL Saya untuk beban kerja terkonsolidasi. Fitur lainnya adalah penskalaan berbasis permintaan, yang dijelaskan dalam Auto Scaling Amazon Aurora dengan Replika Aurora di Panduan Pengguna Amazon Aurora. Fiturnya yang lain adalah keuntungan performa atau operasi basis data yang disederhanakan.

2. Pahami karakteristik beban kerja Anda

Evaluasi Aurora dalam konteks kasus penggunaan yang Anda inginkan. Aurora adalah pilihan yang baik untuk pemrosesan transaksi online (OLTP) beban kerja. Anda juga dapat menjalankan laporan pada klaster yang menyimpan OLTP data real-time tanpa menyediakan klaster gudang data terpisah. Anda dapat mengenali apakah kasus penggunaan Anda termasuk dalam kategori ini atau tidak dengan melihat ciri-ciri berikut:

• Konkurensi yang tinggi, dengan puluhan, ratusan, atau bahkan ribuan klien simultan.

• Kueri berlatensi rendah dalam volume besar (milidetik hingga detik).

• Transaksi singkat dan waktu nyata.

• Pola kueri yang sangat selektif, dengan pencarian berbasis indeks.

• UntukHTAP, kueri analitis yang dapat memanfaatkan kueri paralel Aurora.

Salah satu faktor utama yang memengaruhi pilihan basis data Anda adalah kecepatan datanya. Kecepatan tinggi berkaitan dengan data yang sangat sering disisipkan dan diperbarui. Sistem seperti itu mungkin memiliki ribuan koneksi dan ratusan ribu kueri simultan yang membaca dan menulis ke basis data. Kueri dalam sistem berkecepatan tinggi biasanya akan memengaruhi jumlah baris yang relatif kecil, dan biasanya mengakses beberapa kolom dalam baris yang sama.

Aurora dirancang untuk menangani data berkecepatan tinggi. Bergantung pada beban kerjanya, klaster Aurora dengan satu instans DB r4.16xlarge dapat memproses lebih dari 600.000 pernyataan SELECT per detik. Sekali lagi, bergantung pada beban kerjanya, klaster seperti itu dapat memproses 200.000 pernyataan INSERT, UPDATE, dan DELETE per detik. Aurora adalah database toko baris dan sangat cocok untuk beban kerja volume tinggi, throughput tinggi, dan sangat paralel. OLTP

Aurora juga dapat menjalankan kueri pelaporan pada cluster yang sama yang menangani beban kerja. OLTP Aurora mendukung hingga 15 replika, yang masing-masing memiliki lag replikasi rata-rata 10-20 milidetik dari instans primer. Analis dapat meminta OLTP data secara real time tanpa menyalin data ke cluster gudang data terpisah. Dengan menggunakan fitur kueri paralel untuk klaster Aurora, Anda dapat memindahkan sebagian besar pemrosesan, pemfilteran, dan agregasi ke subsistem penyimpanan Aurora yang didistribusikan secara masif.

Gunakan fase perencanaan ini untuk membiasakan diri dengan kemampuan Aurora, AWS layanan lain AWS Management Console, dan. AWS CLI Selain itu, periksa bagaimana kecocokan fungsinya dengan alat-alat lain yang nantinya Anda gunakan dalam pembuktian konsep.

3. Berlatih dengan AWS Management Console atau AWS CLI

Sebagai langkah selanjutnya, berlatih dengan AWS Management Console atau AWS CLI, untuk menjadi akrab dengan alat-alat ini dan dengan Aurora.

Berlatihlah dengan AWS Management Console

Aktivitas awal berikut dengan cluster database Aurora terutama agar Anda dapat membiasakan diri dengan AWS Management Console lingkungan dan berlatih menyiapkan dan memodifikasi cluster Aurora. Jika Anda menggunakan mesin database My SQL -compatible dan Postgre SQL -compatible dengan AmazonRDS, Anda dapat membangun pengetahuan itu ketika Anda menggunakan Aurora.

Dengan memanfaatkan model dan fitur penyimpanan bersama dari Aurora seperti replikasi dan snapshot, Anda dapat memperlakukan seluruh klaster basis data sebagai jenis objek lain yang dapat Anda manipulasi dengan bebas. Anda dapat menyusun, merombak, dan mengubah kapasitas klaster Aurora selama proses pembuktian konsep. Anda tidak akan terkunci pada pilihan awal tentang kapasitas, pengaturan basis data, dan tata letak data fisik.

Untuk memulai, siapkan klaster Aurora yang kosong. Pilih jenis kapasitas terprovisi dan lokasi wilayah untuk eksperimen awal Anda.

Connect ke cluster itu menggunakan program klien seperti aplikasi SQL command-line. Awalnya, Anda akan terhubung menggunakan titik akhir klaster. Anda terhubung ke titik akhir tersebut untuk melakukan operasi penulisan apa pun, seperti pernyataan bahasa definisi data (DDL) dan proses ekstrak, transformasi, load (ETL). Selanjutnya, dalam pembuktian konsep, Anda perlu menghubungkan sesi sarat kueri menggunakan titik akhir pembaca, yang mendistribusikan beban kerja kueri ke beberapa instans DB di klaster.

Skalakan ke luar klaster dengan menambahkan lebih banyak Replika Aurora. Untuk prosedurnya, lihat Replikasi dengan Amazon Aurora. Skala instance DB naik atau turun dengan mengubah kelas AWS instance. Pahami cara Aurora dapat menyederhanakan jenis operasi ini, sehingga jika perkiraan awal Anda untuk kapasitas sistem tidak akurat, Anda dapat menyesuaikannya nanti tanpa harus memulai dari awal.

Buat snapshot dan pulihkan ke klaster yang berbeda.

Periksa metrik klaster untuk melihat aktivitas dari waktu ke waktu, dan kecocokan metrik tersebut untuk instans DB di klaster.

Sangat berguna untuk menjadi akrab dengan bagaimana melakukan hal-hal ini AWS Management Console di awal. Setelah memahami apa yang dapat Anda lakukan dengan Aurora, Anda dapat melanjutkan untuk mengotomatiskan operasi tersebut menggunakan AWS CLI. Di bagian berikut, Anda dapat menemukan detail lebih lanjut tentang prosedur dan praktik terbaik untuk kegiatan ini selama proof-of-concept periode tersebut.

Berlatihlah dengan AWS CLI

Kami merekomendasikan untuk mengotomatiskan prosedur penerapan dan manajemen, bahkan dalam pengaturan. proof-of-concept Untuk melakukannya, menjadi akrab dengan AWS CLI jika Anda belum melakukannya. Jika Anda menggunakan mesin database My SQL -compatible dan Postgre SQL -compatible dengan AmazonRDS, Anda dapat membangun pengetahuan itu ketika Anda menggunakan Aurora.

Aurora biasanya menangani grup instans DB yang disusun dalam klaster. Dengan demikian, banyak operasi akan mengharuskan Anda menentukan instans DB mana yang terkait dengan sebuah klaster, lalu melakukan operasi administratif dalam satu rangkaian untuk semua instans.

Misalnya, Anda dapat mengotomatiskan langkah-langkah seperti pembuatan klaster Aurora, lalu menaikkan skalanya dengan kelas instans yang lebih besar atau menskalakan klaster tersebut ke luar dengan instans DB tambahan. Dengan demikian, Anda akan dapat mengulangi tahapan mana pun dalam proses pembuktian konsep Anda dan mengkaji skenario bagaimana-jika dengan berbagai jenis atau konfigurasi klaster Aurora.

Pelajari kemampuan dan batasan alat deployment infrastruktur seperti AWS CloudFormation. Anda mungkin menemukan aktivitas yang Anda lakukan dalam proof-of-concept konteks tidak cocok untuk penggunaan produksi. Misalnya, AWS CloudFormation perilaku modifikasi adalah membuat instance baru dan menghapus yang sekarang, termasuk datanya. Untuk detail selengkapnya tentang perilaku ini, lihat Pembaruan perilaku sumber daya tumpukan dalam Panduan Pengguna AWS CloudFormation .

4. Buat klaster Aurora Anda

Dengan Aurora, Anda dapat mengkaji skenario bagaimana-jika dengan menambahkan instans DB ke klaster dan menaikkan skala instans DB ke kelas instans yang berperforma lebih tinggi. Anda juga dapat membuat klaster dengan pengaturan konfigurasi yang berbeda-beda untuk menjalankan beban kerja yang sama secara berdampingan. Dengan Aurora, Anda memiliki banyak fleksibilitas untuk menyiapkan, merombak, dan mengonfigurasi ulang klaster DB. Mengingat hal ini, akan sangat membantu untuk mempraktikkan teknik-teknik ini pada tahap awal proof-of-concept proses. Untuk prosedur umum membuat klaster Aurora, lihat Membuat klaster DB Amazon Aurora.

Jika memungkinkan, mulailah dengan sebuah klaster yang menggunakan pengaturan berikut. Lewati langkah ini jika Anda memiliki kasus penggunaan khusus tertentu. Misalnya, Anda mungkin perlu melewati langkah ini jika kasus penggunaan Anda memerlukan jenis klaster Aurora khusus. Atau Anda dapat melewati langkah ini jika Anda memerlukan kombinasi mesin dan versi basis data khusus.

• Nonaktifkan Pembuatan mudah. Sebagai pembuktian konsep, kami menyarankan Anda untuk mengetahui semua pengaturan yang Anda pilih sehingga Anda dapat membuat klaster yang identik atau sedikit berbeda nantinya.

• Gunakan versi mesin DB terbaru. Kombinasi mesin database dan versi ini memiliki kompatibilitas yang luas dengan fitur Aurora lainnya dan penggunaan pelanggan yang substansif untuk aplikasi produksi.

  • Aurora SQL Versi saya 3.x (Kompatibilitas 8.0 sayaSQL)

  • Aurora Postgre SQL versi 15.x atau 16.x

• Pilih templat Dev/Tes. Pilihan ini tidak signifikan untuk proof-of-concept aktivitas Anda.

• Untuk Kelas instans DB, pilih Kelas teroptimasi memori dan salah satu kelas instans xlarge. Anda dapat menyesuaikan kelas instans ke atas atau ke bawah nantinya.

• Di bagian Deployment Multi-AZ, pilih Buat Replika Aurora atau simpul Pembaca di AZ yang berbeda. Banyak aspek Aurora yang paling berguna menangani klaster yang terdiri dari beberapa instans DB. Sebaiknya mulai selalu dengan setidaknya dua instans DB di klaster baru. Penggunaan Zona Ketersediaan yang berbeda untuk instans DB kedua akan membantu menguji berbagai skenario ketersediaan tinggi.

• Saat memilih nama untuk instans DB, gunakan konvensi penamaan yang generik. Jangan merujuk ke instans DB cluster apa pun sebagai “penulis,” karena instance DB yang berbeda mengambil peran tersebut sesuai kebutuhan. Kami merekomendasikan format seperti clustername-az-serialnumber, misalnya myprodappdb-a-01. Bagian-bagian ini mengidentifikasi secara unik instans DB dan penempatannya.

• Tetapkan retensi cadangan yang tinggi untuk klaster Aurora. Dengan periode retensi yang lama, Anda dapat melakukan point-in-time pemulihan (PITR) untuk jangka waktu hingga 35 hari. Anda dapat mengatur ulang database Anda ke status yang diketahui setelah menjalankan pengujian yang melibatkan DDL dan pernyataan bahasa manipulasi data (DML). Anda juga dapat memulihkannya jika Anda tidak sengaja menghapus atau mengubah data.

• Aktifkan fitur pemulihan, pencatatan log, dan pemantauan tambahan pada pembuatan klaster. Aktifkan semua pilihan yang tersedia di Backtrack, Performance Insights, Monitoring, dan ekspor Log. Dengan mengaktifkan berbagai fitur ini, Anda dapat menguji kesesuaian fitur seperti backtracking, Pemantauan yang Ditingkatkan, atau Wawasan Performa untuk beban kerja Anda. Anda juga dapat dengan mudah memeriksa performa dan melakukan pemecahan masalah selama proses pembuktian konsep.

5. Siapkan skema Anda

Pada klaster Aurora, siapkan basis data, tabel, indeks, kunci asing, dan objek skema lainnya untuk aplikasi Anda. Jika Anda pindah dari sistem database My SQL -compatible atau Postgre SQL -compatible lainnya, harapkan tahap ini sederhana dan mudah. Anda menggunakan SQL sintaks dan baris perintah yang sama atau aplikasi klien lain yang Anda kenal untuk mesin database Anda.

Untuk mengeluarkan SQL pernyataan di klaster Anda, temukan titik akhir klaster dan berikan nilai tersebut sebagai parameter koneksi ke aplikasi klien Anda. Anda dapat menemukan titik akhir klaster di tab Konektivitas di halaman detail klaster Anda. Titik akhir klaster adalah yang berlabel Penulis. Titik akhir lainnya, yang berlabel Pembaca, merepresentasikan koneksi hanya baca yang dapat Anda berikan kepada pengguna akhir yang menjalankan laporan atau kueri hanya baca lainnya. Untuk memperoleh bantuan atas masalah apa pun terkait koneksi ke klaster Anda, lihat Menghubungkan ke klaster DB Amazon Aurora.

Jika Anda mem-porting skema dan data Anda dari sistem basis data yang berbeda, Anda perlu membuat beberapa perubahan skema pada saat ini. Perubahan skema ini sesuai dengan SQL sintaks dan kemampuan yang tersedia di Aurora. Anda dapat menghapus kolom, batasan, pemicu, atau objek skema tertentu pada tahap ini. Dengan melakukannya, Anda akan memperoleh manfaat, terutama jika objek ini memerlukan pengerjaan ulang untuk kompatibilitas Aurora dan tidak signifikan untuk tujuan Anda dengan pembuktian konsep.

Jika Anda bermigrasi dari sistem database dengan mesin dasar yang berbeda dari Aurora, pertimbangkan untuk menggunakan AWS Schema Conversion Tool (AWS SCT) untuk menyederhanakan proses. Untuk detailnya, lihat Panduan Pengguna AWS Schema Conversion Tool. Untuk detail umum tentang aktivitas migrasi dan porting, lihat whitepaper Migrasi Database Anda ke Amazon Aurora. AWS

Selama tahap ini, Anda dapat mengevaluasi apakah terdapat inefisiensi dalam penyiapan skema Anda, misalnya dalam strategi pengindeksan atau struktur tabel lain seperti tabel yang dipartisi. Inefisiensi seperti itu akan meningkat saat Anda men-deploy aplikasi Anda pada klaster dengan beberapa instans DB dan beban kerja yang berat. Pertimbangkan apakah Anda dapat menyempurnakan aspek performa tersebut sekarang, atau selama aktivitas selanjutnya seperti pengujian tolok ukur lengkap.

6. Impor data Anda

Selama pembuktian konsep, Anda akan membawa data, atau sampel representatif, dari sistem basis data sebelumnya. Jika memungkinkan, siapkan setidaknya beberapa data di setiap tabel Anda. Hal tersebut akan membantu menguji kompatibilitas semua jenis data dan fitur skema. Setelah Anda mencoba berbagai fitur Aurora dasar, tingkatkan jumlah datanya. Pada saat Anda menyelesaikan bukti konsep, Anda harus menguji ETL alat, kueri, dan beban kerja Anda secara keseluruhan dengan kumpulan data yang cukup besar untuk menarik kesimpulan yang akurat.

Anda dapat menggunakan beberapa teknik untuk mengimpor data cadangan fisik atau logis ke Aurora. Untuk detail, lihat Migrasi data ke cluster Amazon Aurora My DB SQL atau Migrasi data ke Amazon Aurora dengan kompatibilitas Postgre SQL sesuai dengan mesin basis data yang Anda gunakan dalam bukti konsep.

Bereksperimenlah dengan ETL alat dan teknologi yang sedang Anda pertimbangkan. Lihat mana yang paling sesuai dengan kebutuhan Anda. Pertimbangkan throughput dan fleksibilitasnya. Misalnya, beberapa ETL alat melakukan transfer satu kali, dan yang lain melibatkan replikasi berkelanjutan dari sistem lama ke Aurora.

Jika Anda bermigrasi dari sistem yang SQL kompatibel dengan Saya ke Aurora MySQL, Anda dapat menggunakan alat transfer data asli. Hal yang sama berlaku jika Anda bermigrasi dari SQL sistem yang kompatibel dengan Postgre ke Aurora Postgre. SQL Jika Anda bermigrasi dari sistem database yang menggunakan mesin dasar yang berbeda dari Aurora, Anda dapat bereksperimen dengan AWS Database Migration Service ().AWS DMS Untuk detailnya AWS DMS, lihat Panduan AWS Database Migration Service Pengguna.

Untuk detail tentang aktivitas migrasi dan porting, lihat buku AWS putih buku pegangan migrasi Aurora.

7. Port SQL kode Anda

Mencoba SQL dan aplikasi terkait membutuhkan tingkat upaya yang berbeda tergantung pada kasus yang berbeda. Secara khusus, tingkat upaya tergantung pada apakah Anda pindah dari sistem My SQL -compatible atau Postgre SQL -compatible atau jenis lain.

• Jika Anda pindah dari RDS untuk My SQL atau RDS PostgreSQL, SQL perubahannya cukup kecil sehingga Anda dapat mencoba SQL kode asli dengan Aurora dan secara manual memasukkan perubahan yang diperlukan.

• Demikian pula, jika Anda berpindah dari database lokal yang kompatibel dengan My SQL atau PostgreSQL, Anda dapat mencoba SQL kode asli dan memasukkan perubahan secara manual.

• Jika Anda berasal dari database komersial yang berbeda, SQL perubahan yang diperlukan lebih luas. Dalam hal ini, pertimbangkan untuk menggunakan AWS SCT.

Selama tahap ini, Anda dapat mengevaluasi apakah terdapat inefisiensi dalam penyiapan skema Anda, misalnya dalam strategi pengindeksan atau struktur tabel lain seperti tabel yang dipartisi. Pertimbangkan apakah Anda dapat menyempurnakan aspek performa tersebut sekarang, atau selama aktivitas selanjutnya seperti pengujian tolok ukur lengkap.

Anda dapat memverifikasi logika koneksi basis data di aplikasi Anda. Untuk memanfaatkan pemrosesan terdistribusi Aurora, Anda mungkin perlu menggunakan koneksi terpisah untuk operasi baca dan tulis, dan menggunakan sesi yang relatif singkat untuk operasi kueri. Untuk informasi tentang koneksi, lihat 9. Hubungkan ke Aurora.

Pertimbangkan apakah Anda harus membuat kompromi dan pengorbanan untuk mengatasi masalah dalam basis data produksi Anda. Bangun waktu ke dalam proof-of-concept jadwal untuk melakukan perbaikan pada desain dan kueri skema Anda. Untuk menilai apakah Anda dapat meraih keuntungan dari segi performa, biaya pengoperasian, dan skalabilitas yang baik, coba aplikasi asli dan yang dimodifikasi secara berdampingan di klaster Aurora yang berbeda.

Untuk detail tentang aktivitas migrasi dan porting, lihat buku AWS putih buku pegangan migrasi Aurora.

8. Tentukan pengaturan konfigurasi

Anda juga dapat meninjau parameter konfigurasi database Anda sebagai bagian dari latihan Aurora proof-of-concept . Anda mungkin sudah memiliki pengaturan SQL konfigurasi Saya SQL atau Postgre yang disetel untuk kinerja dan skalabilitas di lingkungan Anda saat ini. Subsistem penyimpanan Aurora diubah dan diatur untuk lingkungan berbasis cloud terdistribusi dengan subsistem penyimpanan berkecepatan tinggi. Akibatnya, banyak pengaturan mesin basis data sebelumnya tidak berlaku. Kami merekomendasikan untuk melakukan eksperimen awal Anda dengan pengaturan konfigurasi Aurora default. Terapkan kembali pengaturan dari lingkungan Anda saat ini hanya jika Anda mengalami hambatan performa dan skalabilitas. Jika Anda tertarik, Anda dapat melihat lebih dalam subjek ini dalam Memperkenalkan mesin penyimpanan Aurora di Blog AWS Database.

Aurora memudahkan penggunaan kembali pengaturan konfigurasi optimal untuk aplikasi atau kasus penggunaan tertentu. Alih-alih mengedit file konfigurasi terpisah untuk setiap instans DB, Anda mengelola sekumpulan parameter yang Anda tetapkan ke seluruh klaster atau instans DB tertentu. Misalnya, pengaturan zona waktu berlaku untuk semua instans DB di klaster, dan Anda dapat menyesuaikan pengaturan ukuran cache halaman untuk setiap instans DB.

Anda memulai dengan salah satu set parameter default, dan menerapkan perubahan ke parameter yang perlu Anda sesuaikan saja. Untuk detail tentang menggunakan grup parameter, lihat Parameter klaster DB dan instans DB Amazon Aurora. Untuk pengaturan konfigurasi yang berlaku atau tidak berlaku untuk klaster Aurora, lihat Aurora Parameter konfigurasi saya SQL atau Parameter Amazon Aurora PostgreSQL tergantung mesin basis data Anda.

9. Hubungkan ke Aurora

Seperti yang Anda temukan saat membuat skema awal dan pengaturan data serta menjalankan kueri sampel, Anda dapat terhubung ke titik akhir yang berbeda-beda dalam klaster Aurora. Titik akhir yang akan digunakan bergantung pada apakah operasinya adalah pembacaan, seperti pernyataan SELECT atau penulisan, seperti pernyataan CREATE atau INSERT. Saat Anda meningkatkan beban kerja pada klaster Aurora dan bereksperimen dengan fitur Aurora, penting bagi aplikasi Anda untuk menetapkan setiap operasi ke titik akhir yang sesuai.

Dengan menggunakan titik akhir klaster untuk operasi penulisan, Anda selalu terhubung ke instans DB di klaster yang memiliki kemampuan baca/tulis. Secara default, hanya satu instans DB dalam klaster Aurora yang memiliki kemampuan baca/tulis. Instans DB ini disebut instans primer. Jika instans primer asli tidak tersedia, Aurora mengaktifkan mekanisme failover dan instans DB yang berbeda akan mengambil alih sebagai instans primer.

Demikian pula, dengan mengarahkan pernyataan SELECT ke titik akhir pembaca, Anda menyebarkan pemrosesan kueri di antara instans DB dalam klaster. Setiap koneksi pembaca ditugaskan ke instance DB yang berbeda menggunakan resolusi round-robinDNS. Melakukan sebagian besar pekerjaan kueri pada Replika Aurora DB hanya-baca mengurangi beban pada instance utama, membebaskannya untuk menangani dan pernyataan. DDL DML

Menggunakan titik akhir ini akan mengurangi ketergantungan pada nama host yang di-hard-coding, dan membantu aplikasi Anda dipulihkan lebih cepat jika ada kegagalan instans DB.

catatan

Aurora juga memiliki titik akhir kustom yang Anda buat. Titik akhir tersebut biasanya tidak diperlukan selama proses pembuktian konsep.

Replika Aurora dapat mengalami lag replika, meskipun lag ini biasanya berlangsung 10 hingga 20 milidetik. Anda bisa memantau lag replikasi dan memutuskan apakah lag ini masih dalam kisaran persyaratan konsistensi data Anda. Dalam beberapa kasus, kueri baca Anda mungkin memerlukan konsistensi baca yang kuat (read-after-writekonsistensi). Jika demikian, Anda dapat terus menggunakan titik akhir klaster dan bukan titik akhir pembaca.

Untuk memanfaatkan kemampuan Aurora secara utuh untuk eksekusi paralel terdistribusi, Anda mungkin perlu mengubah logika koneksinya. Tujuan Anda adalah menghindari pengiriman semua permintaan baca ke instans primer. Replika Aurora hanya baca akan bersiaga, dengan semua data yang sama, untuk menangani pernyataan SELECT. Kodekan logika aplikasi Anda untuk menggunakan titik akhir yang sesuai untuk setiap jenis operasi. Ikuti pedoman umum berikut:

• Hindari menggunakan satu string koneksi hard-code untuk semua sesi basis data.

• Jika praktis, lampirkan operasi tulis seperti DDL dan DML pernyataan dalam fungsi dalam kode aplikasi klien Anda. Dengan demikian, Anda dapat membuat berbagai jenis operasi menggunakan koneksi tertentu.

• Buat fungsi terpisah untuk operasi kueri. Aurora menetapkan setiap koneksi baru dengan titik akhir pembaca ke Replika Aurora yang berbeda untuk menyeimbangkan beban aplikasi sarat baca.

• Untuk operasi yang menangani sekumpulan kueri, tutup dan buka kembali koneksi ke titik akhir pembaca saat setiap kumpulan kueri terkait selesai. Gunakan pooling koneksi jika fiturnya tersedia di tumpukan perangkat lunak Anda. Mengarahkan kueri ke koneksi yang berbeda akan membantu Aurora mendistribusikan beban kerja baca di beberapa instans DB di klaster.

Untuk informasi umum tentang manajemen koneksi dan titik akhir untuk Aurora, lihat Menghubungkan ke klaster DB Amazon Aurora. Untuk menyelam lebih dalam tentang hal ini, lihat Buku pegangan administrator SQL database Aurora saya — Manajemen koneksi.

10. Jalankan beban kerja Anda

Setelah pengaturan skema, data, dan konfigurasi dilakukan, Anda dapat mulai mencoba klaster dengan menjalankan beban kerja Anda. Gunakan beban kerja sebagai bukti konsep yang mencerminkan aspek utama beban kerja produksi Anda. Kami merekomendasikan untuk selalu membuat keputusan tentang kinerja menggunakan tes dan beban kerja dunia nyata daripada tolok ukur sintetis seperti sysbench atau -C. TPC Di mana pun praktis, kumpulkan pengukuran berdasarkan skema, pola kueri, dan volume penggunaan Anda sendiri.

Sebisa mungkin, tiru kondisi sebenarnya yang akan dialami aplikasi yang berjalan nantinya. Misalnya, Anda biasanya menjalankan kode aplikasi pada EC2 instance Amazon di AWS Region yang sama dan virtual private cloud (VPC) yang sama dengan cluster Aurora. Jika aplikasi produksi Anda berjalan pada beberapa EC2 instance yang mencakup beberapa Availability Zone, siapkan proof-of-concept lingkungan Anda dengan cara yang sama. Untuk informasi selengkapnya tentang AWS Wilayah, lihat Wilayah dan Zona Ketersediaan di Panduan RDS Pengguna Amazon. Untuk mempelajari lebih lanjut tentang VPC layanan Amazon, lihat Apa itu AmazonVPC? di Panduan VPC Pengguna Amazon.

Setelah Anda memastikan bahwa fitur dasar aplikasi Anda berfungsi dan Anda dapat mengakses data melalui Aurora, Anda akan dapat mencoba berbagai aspek klaster Aurora. Beberapa fitur yang mungkin ingin Anda coba adalah koneksi konkuren dengan penyeimbangan beban, transaksi konkuren, dan replikasi otomatis.

Pada tahap ini, mekanisme transfer datanya seharusnya sudah dikenal, sehingga Anda dapat menjalankan pengujian dengan proporsi data sampel yang lebih besar.

Di tahap inilah Anda dapat melihat efek dari perubahan pengaturan konfigurasi seperti batas memori dan batas koneksi. Tinjau kembali prosedur yang Anda kaji dalam 8. Tentukan pengaturan konfigurasi.

Anda juga dapat bereksperimen dengan mekanisme seperti membuat dan memulihkan snapshot. Misalnya, Anda dapat membuat cluster dengan kelas AWS instance yang berbeda, jumlah AWS Replicas, dan sebagainya. Kemudian, di setiap klaster, Anda dapat memulihkan snapshot yang sama yang berisi skema dan semua data Anda. Untuk detail tentang siklus tersebut, lihat Membuat snapshot klaster DB dan Memulihkan dari snapshot klaster DB.

11. Ukur performa

Praktik terbaik dalam aspek ini dirancang untuk memastikan bahwa semua alat dan proses disiapkan secara tepat untuk dapat mengisolasi perilaku abnormal selama operasi beban kerja. Praktik terbaik ini juga disiapkan untuk memastikan bahwa Anda dapat mengidentifikasi kemungkinan penyebab masalah yang berlaku.

Anda selalu dapat melihat status klaster Anda saat ini, atau memeriksa tren dari waktu ke waktu, dengan memeriksa tab Pemantauan. Tab ini tersedia dari halaman detail konsol untuk setiap klaster atau instans DB Aurora. Ini menampilkan metrik dari layanan CloudWatch pemantauan Amazon dalam bentuk bagan. Anda dapat memfilter metrik berdasarkan nama, instans DB, dan periode waktu.

Untuk memiliki lebih banyak pilihan di tab Pemantauan, aktifkan Pemantauan yang Ditingkatkan dan Wawasan Performa di pengaturan klaster. Anda juga dapat mengaktifkan pilihan tersebut nanti jika Anda tidak memilihnya saat menyiapkan klaster.

Untuk mengukur performa, Anda sebagian besar akan mengandalkan bagan yang menampilkan aktivitas untuk seluruh klaster Aurora. Anda dapat memastikan apakah Replika Aurora memiliki waktu pemuatan dan waktu respons yang sama. Anda juga dapat melihat pemisahan pekerjaan antara instans primer baca/tulis dan Replika Aurora hanya baca. Jika ada ketidakseimbangan antara instans DB atau masalah yang hanya memengaruhi satu instans DB, Anda dapat memeriksa tab Pemantauan untuk instans yang bermasalah tersebut.

Setelah lingkungan dan beban kerja sebenarnya disiapkan untuk meniru aplikasi produksi Anda, Anda dapat mengukur seberapa baik performa Aurora. Berikut adalah pertanyaan terpenting yang perlu dijawab:

• Berapa banyak kueri per detik yang diproses Aurora? Anda dapat memeriksa metrik Throughput untuk melihat angka untuk berbagai jenis operasi yang ada.

• Berapa lama rata-rata waktu yang diperlukan Aurora untuk memproses kueri tertentu? Anda dapat memeriksa metrik Latensi untuk melihat angka untuk berbagai jenis operasi yang ada.

Untuk melihat metrik throughput dan latensi, periksa tab Monitoring untuk klaster Aurora tertentu di konsol Amazon. RDS Tangkapan layar berikut menunjukkan contoh metrik Select Latency, DMLLatency, Select Throughput, dan DML Throughput pada tab Monitoring.

Jika memungkinkan, tetapkan nilai acuan dasar untuk metrik ini di lingkungan Anda saat ini. Jika tidak memungkinkan, maka buat acuan dasar di klaster Aurora dengan menjalankan beban kerja yang setara dengan aplikasi produksi Anda. Misalnya, jalankan beban kerja Aurora Anda dengan jumlah pengguna dan kueri simultan yang sama. Kemudian, amati perubahan nilainya saat Anda bereksperimen dengan berbagai kelas instans, ukuran klaster, pengaturan konfigurasi, dan sebagainya.

Jika jumlah throughput lebih rendah dari yang Anda harapkan, periksa lebih lanjut faktor-faktor yang memengaruhi performa basis data untuk beban kerja Anda. Selain itu, lakukan pemeriksaan lebih lanjut jika angka latensi lebih tinggi dari yang Anda harapkan. Untuk melakukannya, pantau metrik sekunder untuk server DB (CPU, memori, dan sebagainya). Anda dapat melihat apakah instans DB mulai mendekati batasnya. Anda juga dapat melihat berapa banyak kapasitas ekstra yang dimiliki instans DB Anda untuk menangani lebih banyak kueri konkuren, kueri terhadap tabel yang lebih besar, dan sebagainya.

Tip

Untuk mendeteksi nilai metrik yang berada di luar rentang yang diharapkan, atur CloudWatch alarm.

Saat mengevaluasi ukuran dan kapasitas klaster Aurora yang ideal, Anda akan dapat menemukan konfigurasi yang mendekati performa aplikasi maksimal tanpa penyediaan sumber daya yang berlebihan. Salah satu faktor penting adalah menemukan ukuran yang sesuai untuk instans DB di klaster Aurora. Mulailah dengan memilih ukuran instans yang memiliki kapasitas memori CPU dan serupa dengan lingkungan produksi Anda saat ini. Kumpulkan angka throughput dan latensi untuk beban kerja pada ukuran instans tersebut. Kemudian, naikkan skala instans ini ke ukuran yang lebih besar berikutnya. Lihat apakah angka throughput dan latensi menjadi bertambah baik. Selain itu, turunkan ukuran instans, dan lihat apakah angka latensi dan throughput tetap sama. Sasaran Anda adalah mendapatkan throughput tertinggi, dengan latensi terendah, pada instans sekecil mungkin.

Tip

Tentukan ukuran klaster Aurora Anda dan instans DB terkait dengan kapasitas yang cukup untuk menangani lonjakan lalu lintas yang tiba-tiba dan tidak dapat diprediksi. Untuk database mission-critical, sisakan setidaknya 20 persen kapasitas cadangan CPU dan memori.

Jalankan uji performa selama mungkin untuk mengukur performa basis data dalam kondisi siap dan stabil. Anda mungkin perlu menjalankan beban kerja selama beberapa menit atau bahkan beberapa jam sebelum mencapai kondisi stabil ini. Varians yang bermunculan di awal proses menjalankan beban kerja adalah hal yang normal. Varians tersebut terjadi karena setiap Replika Aurora menyiapkan cache-nya berdasarkan kueri SELECT yang ditanganinya.

Aurora beperforma paling baik untuk beban kerja transaksional yang menangani beberapa pengguna dan kueri secara bersamaan. Untuk memastikan bahwa Anda memiliki beban yang cukup untuk performa yang optimal, jalankan penilaian tolok ukur yang menggunakan multithreading, atau jalankan beberapa uji performa secara bersamaan. Ukur performa dengan ratusan atau bahkan ribuan thread konkuren klien. Simulasikan jumlah thread konkuren yang Anda perkirakan di dalam lingkungan produksi Anda. Anda juga dapat melakukan uji stres tambahan dengan lebih banyak thread untuk mengukur skalabilitas Aurora.

12. Coba ketersediaan tinggi Aurora

Sebagian besar fitur utama Aurora mendukung ketersediaan yang tinggi. Fitur-fitur ini termasuk replikasi otomatis, failover otomatis, backup otomatis dengan point-in-time restore, dan kemampuan untuk menambahkan instans DB ke cluster. Keamanan dan keandalan dari fitur-fitur seperti ini penting untuk aplikasi yang bersifat vital.

Pola pikir tertentu diperlukan untuk mengevaluasi fitur tersebut. Dalam aktivitas sebelumnya, seperti pengukuran performa, Anda mengamati bagaimana sistem berfungsi ketika semuanya dapat bekerja dengan benar. Menguji ketersediaan tinggi mengharuskan Anda mempertimbangkan perilaku kasus terburuk. Anda harus mempertimbangkan potensi berbagai macam kegagalan, sekalipun kondisi kegagalan tersebut jarang terjadi. Anda dapat sengaja menimbulkan masalah untuk memastikan bahwa sistem dipulihkan dengan benar dan cepat.

Tip

Untuk bukti konsep, siapkan semua instance DB di cluster Aurora dengan kelas instance AWS yang sama. Dengan melakukannya, Anda akan dapat mencoba fitur ketersediaan Aurora tanpa perubahan besar pada performa dan skalabilitas saat Anda membuat instans DB offline untuk mensimulasikan kegagalan.

Kami merekomendasikan penggunaan setidaknya dua instans di setiap klaster Aurora. Instans DB dalam cluster Aurora dapat menjangkau hingga tiga Availability Zones AZs (). Tempatkan dua atau tiga instans DB pertama di AZ yang berbeda. Saat Anda mulai menggunakan cluster yang lebih besar, sebarkan instans DB Anda di semua wilayah Anda AWS . AZs Dengan melakukannya, kemampuan toleransi kesalahan akan meningkat. Bahkan jika ada masalah yang memengaruhi seluruh AZ, Aurora dapat beralih ke instans DB di AZ yang berbeda. Jika Anda menjalankan cluster dengan lebih dari tiga instance, distribusikan instans DB secara merata sebanyak yang Anda bisa di ketiganya. AZs

Tip

Penyimpanan untuk klaster Aurora tidak tergantung pada instans DB. Penyimpanan untuk setiap cluster Aurora selalu mencakup tiga. AZs

Saat Anda menguji fitur ketersediaan tinggi, selalu gunakan instans DB dengan kapasitas yang sama di klaster pengujian Anda. Hal tersebut akan menghindari perubahan yang tidak dapat diprediksi dalam performa, latensi, dan sebagainya setiap kali ada satu instans DB yang mengambil alih instans DB lain.

Untuk mempelajari cara mensimulasikan kondisi kegagalan untuk menguji fitur ketersediaan tinggi, lihat Menguji Amazon Aurora My SQL menggunakan kueri injeksi kesalahan.

Sebagai bagian dari proof-of-concept latihan Anda, salah satu tujuannya adalah untuk menemukan jumlah instans DB yang ideal dan kelas instans optimal untuk instans DB tersebut. Untuk melakukannya, diperlukan keseimbangan antara ketersediaan tinggi dan performa.

Untuk Aurora, semakin banyak instans DB yang Anda miliki dalam sebuah klaster, semakin besar manfaat untuk ketersediaan tinggi. Memiliki lebih banyak instans DB juga meningkatkan skalabilitas aplikasi sarat baca. Aurora dapat mendistribusikan beberapa koneksi untuk kueri SELECT di beberapa Replika Aurora hanya baca.

Di sisi lain, membatasi jumlah instans DB akan mengurangi lalu lintas replikasi dari simpul primer. Lalu lintas replikasi akan menggunakan bandwidth jaringan, yang merupakan aspek lain dari performa dan skalabilitas secara keseluruhan. Jadi, untuk OLTP aplikasi intensif tulis, lebih suka memiliki jumlah instans DB besar yang lebih kecil daripada banyak instans DB kecil.

Dalam cluster Aurora yang khas, satu instance DB (instance utama) menangani semua pernyataan DDL danDML. Instans DB lainnya (Replika Aurora) hanya menangani pernyataan SELECT. Meskipun instans DB tidak melakukan jumlah pekerjaan yang persis sama, kami merekomendasikan penggunaan kelas instans yang sama untuk semua instans DB dalam klaster. Dengan begitu, jika terjadi kegagalan dan Aurora menjadikan salah satu instans DB hanya baca sebagai instans primer yang baru, instans primer ini akan memiliki kapasitas yang sama seperti sebelumnya.

Jika Anda perlu menggunakan instans DB dengan kapasitas berbeda dalam klaster yang sama, maka atur tingkat failover untuk instans DB. Tingkatan ini menentukan urutan promosi Replika Aurora oleh mekanisme failover. Tempatkan instans DB yang jauh lebih besar atau lebih kecil dari yang lain ke tingkat failover yang lebih rendah. Dengan melakukannya, Anda akan memastikan bahwa instans tersebut akan dipilih terakhir untuk promosi.

Latih fitur pemulihan data Aurora, seperti pemulihan otomatis, snapshot dan point-in-time pemulihan manual, dan backtracking cluster. Jika sesuai, salin snapshot ke AWS Wilayah lain dan pulihkan ke AWS Wilayah lain untuk meniru skenario DR.

Selidiki persyaratan organisasi Anda untuk tujuan waktu pemulihan (RTO), tujuan titik pemulihan (RPO), dan redundansi geografis. Sebagian besar organisasi mengelompokkan item ini ke dalam kategori pemulihan bencana. Evaluasi fitur ketersediaan tinggi Aurora yang dijelaskan dalam bagian ini dalam konteks proses pemulihan bencana Anda untuk memastikan bahwa Anda RTO dan RPO persyaratan terpenuhi.

13. Apa yang harus dilakukan selanjutnya

Di akhir proof-of-concept proses yang sukses, Anda mengonfirmasi bahwa Aurora adalah solusi yang cocok untuk Anda berdasarkan beban kerja yang diantisipasi. Sepanjang proses sebelumnya, Anda telah memeriksa cara kerja Aurora dalam lingkungan operasional yang realistis dan mengukurnya dengan kriteria kesuksesan Anda.

Setelah lingkungan basis data Anda aktif dan berfungsi dengan Aurora, Anda dapat melanjutkan ke langkah evaluasi yang lebih mendetail, yang mengarah ke migrasi akhir dan deployment produksi. Tergantung pada situasi Anda, langkah-langkah lain ini mungkin atau mungkin tidak termasuk dalam proof-of-concept proses. Untuk detail tentang aktivitas migrasi dan porting, lihat buku AWS putih buku pegangan migrasi Aurora.

Di langkah berikutnya, pertimbangkan konfigurasi keamanan yang relevan dengan beban kerja Anda dan yang dirancang untuk memenuhi persyaratan keamanan Anda dalam lingkungan produksi. Rencanakan kontrol apa yang akan diterapkan untuk melindungi akses ke kredensial pengguna master klaster Aurora. Tentukan peran dan tanggung jawab pengguna basis data untuk mengontrol akses ke data yang disimpan di klaster Aurora. Pertimbangkan persyaratan akses basis data untuk aplikasi, skrip, dan alat atau layanan pihak ketiga. Jelajahi AWS layanan dan fitur seperti AWS Secrets Manager dan AWS Identity and Access Management (IAM) otentikasi.

Pada tahap ini, Anda akan memahami prosedur dan praktik terbaik untuk menjalankan pengujian penilaian tolok ukur dengan Aurora. Anda mungkin perlu melakukan penyesuaian performa tambahan. Untuk detailnya, lihat Mengelola performa dan penskalaan untuk klaster DB Aurora, Peningkatan performa Amazon Aurora MySQL, Kinerja dan penskalaan untuk Amazon Aurora Postgre SQL, dan Memantau beban DB dengan Performance Insights di Amazon Aurora. Jika Anda melakukan penyesuaian tambahan, pastikan Anda memahami metrik yang Anda kumpulkan selama pembuktian konsep. Untuk langkah berikutnya, Anda mungkin perlu membuat klaster baru dengan pilihan berbeda untuk pengaturan konfigurasi, mesin basis data, dan versi basis data. Anda juga dapat membuat jenis klaster Aurora khusus untuk menyesuaikan dengan kebutuhan kasus penggunaan tertentu.

Misalnya, Anda dapat menjelajahi klaster kueri paralel Aurora untuk aplikasi transaksi/pemrosesan analitik hibrid (). HTAP Jika distribusi geografis yang luas sangat penting untuk pemulihan bencana atau untuk meminimalkan latensi, Anda dapat mengkaji basis data global Aurora. Jika beban kerja Anda bersifat intermiten atau Anda menggunakan Aurora dalam skenario pengembangan/pengujian, Anda dapat mengkaji klaster Aurora Serverless.

Klaster produksi Anda mungkin juga perlu menangani koneksi masuk dalam jumlah yang besar. Untuk mempelajari teknik-teknik tersebut, lihat AWS whitepaper Buku pegangan administrator SQL database Aurora My — Manajemen koneksi.

Jika, setelah pembuktian konsep, Anda memutuskan bahwa kasus penggunaan Anda tidak sesuai untuk Aurora, pertimbangkan layanan AWS lainnya berikut ini:

• Untuk kasus penggunaan analitik murni, beban kerja mendapat manfaat dari format penyimpanan kolumnar dan fitur lain yang lebih cocok untuk beban kerja. OLAP AWS layanan yang menangani kasus penggunaan tersebut meliputi:

  • Amazon Redshift

  • Amazon EMR

  • Amazon Athena

• Sebagian besar beban kerja akan mendapatkan keuntungan dari kombinasi Aurora dengan satu atau beberapa layanan ini. Anda dapat memindahkan data di antara layanan-layanan ini dengan menggunakan hal berikut ini:

  • AWS Glue

  • AWS DMS

  • Mengimpor dari Amazon S3, sebagaimana dijelaskan di Panduan Pengguna Amazon Aurora

  • Mengekspor ke Amazon S3, sebagaimana dijelaskan di Panduan Pengguna Amazon Aurora

  • Banyak ETL alat populer lainnya