Mengkloning volume untuk klaster DB Amazon Aurora - Amazon Aurora
Gambaran umum kloning AuroraBatasan kloning AuroraCara kerja kloning AuroraMembuat klon AuroraKloning lintas-VPCKloning lintas akun

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengkloning volume untuk klaster DB Amazon Aurora

Dengan menggunakan kloning Aurora, Anda dapat membuat klaster baru yang memiliki halaman data yang sama dengan aslinya, tetapi merupakan volume terpisah dan independen. Prosesnya dirancang agar cepat dan hemat biaya. Klaster baru dengan volume data terkaitnya dikenal sebagai Klon. Membuat klon lebih cepat dan lebih hemat ruang daripada menyalin data secara fisik menggunakan teknik lain, seperti memulihkan snapshot.

Gambaran umum kloning Aurora

Aurora menggunakan copy-on-write protokol untuk membuat klon. Mekanisme ini menggunakan ruang tambahan minimal untuk membuat klon awal. Ketika klon pertama kali dibuat, Aurora mempertahankan satu salinan data yang digunakan oleh klaster DB Aurora sumber dan klaster DB Aurora yang baru (klon). Penyimpanan tambahan dialokasikan hanya ketika perubahan dibuat pada data (pada volume penyimpanan Aurora) oleh klaster DB Aurora sumber atau klon klaster DB Aurora. Untuk mempelajari lebih lanjut tentang copy-on-write protokol, lihatCara kerja kloning Aurora.

Kloning Aurora sangat berguna untuk menyiapkan lingkungan pengujian dengan cepat menggunakan data produksi Anda, tanpa risiko kerusakan data. Anda dapat menggunakan klon untuk berbagai jenis aplikasi, seperti berikut:

  • Bereksperimen dengan potensi perubahan (misalnya, perubahan skema dan perubahan grup parameter) untuk menilai semua dampak.

  • Menjalankan operasi sarat beban kerja, seperti mengekspor data atau menjalankan kueri analitis.

  • Membuat salinan dari klaster DB produksi Anda untuk pengembangan, pengujian, atau tujuan lainnya.

Anda dapat membuat lebih dari satu klon dari klaster DB Aurora yang sama. Anda juga dapat membuat beberapa klon dari klon lain.

Setelah membuat klon Aurora, Anda dapat mengonfigurasi instans DB Aurora secara berbeda dari klaster DB Aurora sumber. Misalnya, Anda mungkin tidak memerlukan klon untuk tujuan pengembangan guna memenuhi persyaratan ketersediaan tinggi yang sama dengan klaster DB Aurora produksi. Dalam hal ini, Anda dapat mengonfigurasi klon dengan satu instans DB Aurora dan bukan beberapa instans DB yang digunakan oleh klaster DB Aurora.

Saat Anda membuat klon menggunakan konfigurasi penyebaran yang berbeda dari sumbernya, klon dibuat menggunakan versi minor terbaru dari mesin Aurora DB sumber.

Saat Anda membuat klon dari cluster Aurora DB Anda, klon dibuat di AWS akun Anda—akun yang sama yang memiliki cluster Aurora DB sumber. Namun, Anda juga dapat berbagi Aurora Serverless v2 dan menyediakan cluster dan klon Aurora DB dengan akun lain. AWS Untuk informasi selengkapnya, lihat Kloning lintas akun dengan AWS RAM dan Amazon Aurora.

Setelah selesai menggunakan klon untuk pengujian, pengembangan, atau tujuan lainnya, Anda dapat menghapusnya.

Batasan kloning Aurora

Kloning Aurora saat ini memiliki batasan berikut:

  • Anda dapat membuat klon sebanyak yang Anda inginkan, hingga jumlah maksimum klaster DB yang diizinkan di Wilayah AWS.

    Anda dapat membuat klon menggunakan copy-on-write protokol atau protokol salinan lengkap. Protokol salinan lengkap bertindak seperti point-in-time pemulihan.

  • Anda tidak dapat membuat klon di AWS Wilayah yang berbeda dari cluster Aurora DB sumber.

  • Anda tidak dapat membuat klon dari klaster DB Aurora tanpa fitur kueri paralel ke klaster yang menggunakan kueri paralel. Untuk memasukkan data ke dalam klaster yang menggunakan kueri paralel, buat snapshot dari klaster asli dan pulihkan ke klaster yang menggunakan fitur opsi kueri pararel.

  • Anda tidak dapat membuat klon dari klaster DB Aurora yang tidak memiliki instans DB. Anda hanya dapat mengkloning klaster DB Aurora yang memiliki setidaknya satu instans DB.

  • Anda dapat membuat klon di cloud privat virtual (VPC) yang berbeda dari klaster DB Aurora. Jika Anda melakukannya, subnet VPC harus dipetakan ke Zona Ketersediaan yang sama.

  • Anda dapat membuat klon terprovisi Aurora dari klaster Aurora DB terprovisi.

  • Klaster dengan instans Aurora Serverless v2 mengikuti aturan yang sama dengan klaster terprovisi.

  • Untuk Aurora Serverless v1:

    • Anda dapat membuat klon yang disediakan dari cluster DB. Aurora Serverless v1

    • Anda dapat membuat Aurora Serverless v1 klon dari cluster DB Aurora Serverless v1 atau yang disediakan.

    • Anda tidak dapat membuat klon dari Aurora Serverless v1 klaster Aurora DB yang tidak terenkripsi dan disediakan.

    • Kloning lintas akun saat ini tidak mendukung kloning klaster DB Aurora Serverless v1. Untuk informasi selengkapnya, lihat Batasan kloning lintas akun.

    • Klaster DB Aurora Serverless v1 hasil klon memiliki perilaku dan batasan yang sama dengan klaster DB Aurora Serverless v1 lainnya. Untuk informasi selengkapnya, lihat Menggunakan Amazon Aurora Serverless v1.

    • Klaster DB Aurora Serverless v1 selalu terenkripsi. Ketika Anda mengkloning sebuah klaster DB Aurora Serverless v1 ke klaster DB Aurora, klaster DB Aurora DB terprovisi akan dienkripsi. Anda dapat memilih kunci enkripsi, tetapi tidak dapat menonaktifkan enkripsi. Untuk mengkloning dari cluster Aurora DB yang disediakan ke cluster, Anda harus mulai dengan cluster Aurora Serverless v1 Aurora DB yang disediakan terenkripsi.

Cara kerja kloning Aurora

Kloning Aurora beroperasi pada lapisan penyimpanan klaster DB Aurora. Kloning Aurora menggunakan protokol copy-on-write yang cepat dan hemat ruang pada media durabel yang mendasarinya, yang mendukung volume penyimpanan Aurora. Anda dapat mempelajari selengkapnya tentang volume klaster Aurora dalam Gambaran umum penyimpanan Amazon Aurora.

Memahami copy-on-write protokol

Sebuah klaster DB Aurora menyimpan data dalam halaman di volume penyimpanan Aurora yang mendasarinya.

Misalnya, dalam diagram berikut, Anda dapat menemukan klaster DB Aurora (A) yang memiliki empat halaman data, 1, 2, 3, dan 4. Bayangkan bahwa sebuah klon, B, dibuat dari klaster DB Aurora. Saat klon dibuat, tidak ada data yang disalin. Sebagai gantinya, klon tersebut menunjuk ke kumpulan halaman yang sama sebagai sumber klaster DB Aurora.

Volume klaster Amazon Aurora dengan 4 halaman untuk klaster sumber, A, dan klon, B

Saat klon dibuat, tidak ada penyimpanan tambahan yang biasanya diperlukan. copy-on-write Protokol menggunakan segmen yang sama pada media penyimpanan fisik sebagai segmen sumber. Penyimpanan tambahan hanya diperlukan jika kapasitas segmen sumber tidak cukup untuk seluruh segmen klon. Jika demikian, segmen sumber disalin ke perangkat fisik lain.

Dalam diagram berikut, Anda dapat menemukan contoh copy-on-write protokol yang sedang beraksi menggunakan cluster A yang sama dan klonnya, B, seperti yang ditunjukkan sebelumnya. Katakanlah bahwa Anda membuat perubahan pada klaster DB Aurora (A) yang menghasilkan perubahan pada data yang disimpan di halaman 1. Alih-alih menulis ke halaman 1 asli, Aurora membuat halaman baru 1[A]. Volume klaster DB Aurora untuk klaster (A) sekarang menunjuk ke halaman 1[A], 2, 3, dan 4, sedangkan klon (B) masih merujuk ke halaman asli.

Volume klaster DB sumber Amazon Aurora dan kloningnya, keduanya dengan perubahan.

Pada klon, perubahan dibuat pada halaman 4 di volume penyimpanan. Alih-alih menulis ke halaman 4 asli, Aurora membuat halaman baru 4[B]. Klon sekarang menunjuk ke halaman 1, 2, 3, dan halaman 4[B], sementara klaster (A) terus menunjuk ke 1[A], 2, 3, dan 4.

Volume klaster DB sumber Amazon Aurora dan kloningnya, keduanya dengan perubahan.

Saat lebih banyak perubahan terjadi seiring waktu di volume klaster DB Aurora sumber dan klon, diperlukan lebih banyak penyimpanan untuk menangkap dan menyimpan perubahan tersebut.

Menghapus volume klaster sumber

Awalnya, volume klon berbagi halaman data yang sama dengan volume asli dari mana klon dibuat. Selama volume asli ada, volume klon hanya dianggap sebagai pemilik halaman yang dibuat atau dimodifikasi oleh klon. Dengan demikian, VolumeBytesUsed metrik untuk volume klon mulai kecil dan hanya tumbuh saat data menyimpang antara cluster asli dan klon. Untuk halaman yang identik antara volume sumber dan klon, biaya penyimpanan hanya berlaku untuk cluster asli. Untuk informasi lebih lanjut tentang VolumeBytesUsed metrik, lihatMetrik tingkat klaster untuk Amazon Aurora.

Saat Anda menghapus volume cluster sumber yang memiliki satu atau lebih klon yang terkait dengannya, data dalam volume klon klon tidak berubah. Aurora menyimpan halaman yang sebelumnya dimiliki oleh volume cluster sumber. Aurora mendistribusikan kembali tagihan penyimpanan untuk halaman yang dimiliki oleh cluster yang dihapus. Misalnya, misalkan cluster asli memiliki dua klon dan kemudian cluster asli dihapus. Setengah dari halaman data yang dimiliki oleh cluster asli sekarang akan dimiliki oleh satu klon. Setengah halaman lainnya akan dimiliki oleh klon lainnya.

Jika Anda menghapus cluster asli, maka saat Anda membuat atau menghapus lebih banyak klon, Aurora terus mendistribusikan kembali kepemilikan halaman data di antara semua klon yang berbagi halaman yang sama. Dengan demikian, Anda mungkin menemukan bahwa nilai VolumeBytesUsed metrik berubah untuk volume cluster klon. Nilai metrik dapat menurun karena lebih banyak klon dibuat dan kepemilikan halaman tersebar di lebih banyak cluster. Nilai metrik juga dapat meningkat karena klon dihapus dan kepemilikan halaman ditetapkan ke sejumlah kecil cluster. Untuk informasi tentang bagaimana operasi penulisan memengaruhi halaman data pada volume klon, lihatMemahami copy-on-write protokol.

Ketika cluster asli dan klon dimiliki oleh AWS akun yang sama, semua biaya penyimpanan untuk cluster tersebut berlaku untuk akun yang sama AWS . Jika beberapa cluster adalah klon lintas akun, menghapus cluster asli dapat mengakibatkan biaya penyimpanan tambahan ke AWS akun yang memiliki klon lintas akun.

Misalnya, misalkan volume cluster memiliki 1000 halaman data yang digunakan sebelum Anda membuat klon apa pun. Saat Anda mengkloning cluster itu, awalnya volume klon memiliki nol halaman yang digunakan. Jika klon membuat modifikasi ke 100 halaman data, hanya 100 halaman yang disimpan pada volume klon dan ditandai sebagai yang digunakan. 900 halaman lain yang tidak berubah dari volume induk dibagikan oleh kedua cluster. Dalam hal ini, cluster induk memiliki biaya penyimpanan untuk 1000 halaman dan volume klon untuk 100 halaman.

Jika Anda menghapus volume sumber, biaya penyimpanan untuk klon termasuk 100 halaman yang diubah, ditambah 900 halaman bersama dari volume asli, dengan total 1000 halaman.

Membuat klon Amazon Aurora

Anda dapat membuat klon di AWS akun yang sama dengan cluster Aurora DB sumber. Untuk melakukannya, Anda dapat menggunakan AWS Management Console atau AWS CLI dan prosedur berikut.

Untuk mengizinkan AWS akun lain membuat klon atau berbagi klon dengan AWS akun lain, gunakan prosedur di. Kloning lintas akun dengan AWS RAM dan Amazon Aurora

Prosedur berikut menjelaskan cara mengkloning klaster DB Aurora menggunakan AWS Management Console.

Membuat klon menggunakan AWS Management Console hasil dalam cluster Aurora DB dengan satu instance Aurora DB.

Instruksi ini berlaku untuk cluster DB yang dimiliki oleh AWS akun yang sama yang membuat klon. Jika cluster DB dimiliki oleh AWS akun yang berbeda, lihat Kloning lintas akun dengan AWS RAM dan Amazon Aurora sebagai gantinya.

Untuk membuat tiruan dari cluster DB yang dimiliki oleh AWS akun Anda menggunakan AWS Management Console

  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Basis data.

  3. Pilih klaster DB Aurora Anda dari daftar, dan untuk Tindakan pilih Buat klon.

    Membuat klon dimulai dengan memilih klaster DB Aurora Anda.

    Halaman Buat klon terbuka, yang memungkinkan Anda mengonfigurasi Pengaturan, Konektivitas, dan opsi lain untuk klon klaster DB Aurora.

  4. Untuk Pengidentifikasi instans DB, masukkan nama yang ingin Anda berikan ke klaster DB Aurora Anda.

  5. Untuk cluster Aurora Serverless v1 DB, pilih Provisioned atau Serverless untuk tipe Kapasitas.

    Anda dapat memilih Nirserver hanya jika klaster DB Aurora sumber adalah klaster DB Aurora Serverless v1 atau klaster DB Aurora terprovisi yang dienkripsi.

  6. Untuk Aurora Serverless v2 atau klaster DB yang disediakan, pilih salah satu Aurora I/O-Optimizedatau Aurora Standarduntuk konfigurasi penyimpanan Cluster.

    Untuk informasi selengkapnya, lihat Konfigurasi penyimpanan untuk klaster DB Amazon Aurora.

  7. Pilih ukuran instans DB atau kapasitas klaster DB:

    • Untuk klon yang disediakan, pilih kelas instans DB.

      Untuk membuat klon yang disediakan, tentukan ukuran instans DB.

      Anda dapat menerima pengaturan yang disediakan, atau Anda dapat menggunakan kelas instans DB yang berbeda untuk klon Anda.

    • Untuk Aurora Serverless v1 atau Aurora Serverless v2 klon, pilih pengaturan Kapasitas.

      Untuk membuat klon Serverless dari klaster DB Aurora, tentukan kapasitas.

      Anda dapat menerima pengaturan yang disediakan, atau Anda dapat mengubahnya untuk klon Anda.

  8. Pilih pengaturan lain sesuai kebutuhan untuk klon Anda. Untuk mempelajari selengkapnya tentang klaster DB Aurora dan pengaturan instans, lihat Membuat klaster DB Amazon Aurora.

  9. Pilih Buat klon.

Ketika dibuat, klon akan tercantum dengan klaster DB Aurora Anda lainnya di bagian Basis data pada konsol dan menampilkan statusnya saat ini. Klon Anda siap digunakan ketika statusnya Tersedia.

Menggunakan AWS CLI untuk mengkloning cluster Aurora DB Anda melibatkan beberapa langkah.

restore-db-cluster-to-point-in-time AWS CLI Perintah yang Anda gunakan menghasilkan cluster Aurora DB kosong dengan 0 instance Aurora DB. Artinya, perintah tersebut hanya memulihkan klaster DB Aurora, bukan instans DB untuk klaster tersebut. Anda melakukannya secara terpisah setelah klon tersedia. Dua langkah dalam proses ini adalah sebagai berikut:

  1. Buat klon dengan menggunakan perintah CLI restore-db-cluster-to-point-in-time. Parameter yang Anda gunakan dengan perintah ini mengontrol jenis kapasitas dan detail lain dari klaster DB Aurora kosong (klon) yang dibuat.

  2. Buat instans DB Aurora untuk klon dengan menggunakan perintah CLI create-db-instance untuk membuat instans DB Aurora di klaster DB Aurora yang dipulihkan.

Membuat klon

Parameter tertentu yang Anda teruskan ke perintah CLI restore-db-cluster-to-point-in-time akan bervariasi. Apa yang Anda teruskan tergantung pada jenis mode mesin klaster DB sumber—Serverless atau Terprovisi—dan jenis klon yang ingin Anda buat.

Untuk membuat klon dari mode mesin yang sama sebagai klaster DB Aurora sumber

  • Gunakan perintah CLI restore-db-cluster-to-point-in-time dan tentukan nilai untuk parameter berikut:

    • --db-cluster-identifier – Pilih nama yang bermakna untuk klon anda. Anda menamai klon ketika Anda menggunakan perintah CLI restore-db-cluster-to-point-in-time. Anda kemudian meneruskan nama klon ini di perintah CLI create-db-instance.

    • --restore-type – Gunakan copy-on-write untuk membuat klon dari klaster DB sumber. Tanpa parameter ini, restore-db-cluster-to-point-in-time akan memulihkan klaster DB Aurora dan bukan membuat klon.

    • --source-db-cluster-identifier – Gunakan nama klaster DB Aurora sumber yang ingin Anda kloning.

    • --use-latest-restorable-time— Nilai ini menunjuk ke data volume terbaru yang dapat dipulihkan untuk cluster DB sumber. Gunakan untuk membuat klon.

Contoh berikut membuat klon bernama my-clone dari klaster bernama my-source-cluster.

Untuk Linux, macOS, atau Unix:

aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Untuk Windows:

aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Perintah tersebut menghasilkan objek JSON yang berisi detail klon. Periksa untuk memastikan bahwa klaster DB yang Anda kloning tersedia sebelum mencoba membuat instans DB untuk klon Anda. Untuk informasi selengkapnya, lihat Memeriksa status dan mendapatkan detail klon.

Untuk membuat klon dengan mode mesin yang berbeda dari sumber Aurora DB cluster

  • Gunakan perintah CLI restore-db-cluster-to-point-in-time dan tentukan nilai untuk parameter berikut:

    • --db-cluster-identifier – Pilih nama yang bermakna untuk klon anda. Anda menamai klon ketika Anda menggunakan perintah CLI restore-db-cluster-to-point-in-time. Anda kemudian meneruskan nama klon ini di perintah CLI create-db-instance.

    • --source-db-cluster-identifier – Gunakan nama klaster DB Aurora sumber yang ingin Anda kloning.

    • --restore-type – Gunakan copy-on-write untuk membuat klon dari klaster DB sumber. Tanpa parameter ini, restore-db-cluster-to-point-in-time akan memulihkan klaster DB Aurora dan bukan membuat klon.

    • --use-latest-restorable-time— Nilai ini menunjuk ke data volume terbaru yang dapat dipulihkan untuk cluster DB sumber. Gunakan untuk membuat klon.

    • --engine-mode— (Opsional) Gunakan parameter ini hanya untuk membuat klon yang dari jenis yang berbeda dari sumber Aurora DB cluster. Pilih nilai yang akan diteruskan dengan --engine-mode sebagai berikut:

      • Gunakan provisioned untuk membuat klon klaster DB Aurora terprovisi dari klaster DB Aurora Serverless.

      • Gunakan serverless untuk membuat klon klaster DB Aurora Serverless v1 dari klaster DB Aurora terprovisi. Saat Anda menentukan mode serverless mesin, Anda juga dapat memilih--scaling-configuration.

    • --scaling-configuration— (Opsional) Gunakan dengan --engine-mode serverless untuk mengkonfigurasi kapasitas minimum dan maksimum untuk Aurora Serverless v1 klon. Jika Anda tidak menggunakan parameter ini, Aurora membuat klon menggunakan nilai kapasitas default untuk mesin DB.

    • --serverless-v2-scaling-configuration— (Opsional) Gunakan parameter ini untuk mengonfigurasi kapasitas minimum dan maksimum untuk Aurora Serverless v2 klon. Jika Anda tidak menggunakan parameter ini, Aurora membuat klon menggunakan nilai kapasitas default untuk mesin DB.

Contoh berikut membuat Aurora Serverless v1 klon bernamamy-clone, dari cluster Aurora DB yang disediakan bernama. my-source-cluster Klaster DB Aurora terprovisi akan dienkripsi.

Untuk Linux, macOS, atau Unix:

aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --engine-mode serverless \
    --scaling-configuration MinCapacity=8,MaxCapacity=64 \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Untuk Windows:

aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --engine-mode serverless ^
    --scaling-configuration MinCapacity=8,MaxCapacity=64 ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Perintah ini menghasilkan objek JSON yang berisi detail klon yang Anda butuhkan untuk membuat instans DB. Anda tidak dapat melakukannya sampai klon (klaster DB Aurora kosong) memiliki status Tersedia.

catatan

Perintah AWS CLI restore-db-cluster-to-point-in-time hanya memulihkan klaster DB, bukan instans DB untuk klaster tersebut. Anda harus menginvokasi perintah create-db-instance untuk membuat instans DB untuk klaster DB yang dipulihkan, dengan menentukan pengidentifikasi klaster DB yang dipulihkan dalam --db-cluster-identifier. Anda dapat membuat instans DB hanya setelah perintah restore-db-cluster-to-point-in-time selesai dan klaster DB tersedia.

Misalnya, anggap Anda memiliki klaster bernama tpch100g yang ingin Anda kloning. Contoh Linux berikut membuat klaster yang dikloning bernama tpch100g-clone dan instans primer bernama tpch100g-clone-instance untuk klaster baru. Anda tidak perlu menyediakan beberapa parameter, seperti --master-username dan --master-user-password. Aurora secara otomatis menentukannya dari klaster asli. Anda perlu menentukan mesin DB yang akan digunakan. Dengan demikian, uji coba klaster baru untuk menentukan nilai yang tepat yang akan digunakan untuk parameter --engine.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --restore-type copy-on-write \
  --use-latest-restorable-time

$ aws rds describe-db-clusters \
  --db-cluster-identifier tpch100g-clone \
    --query '*[].[Engine]' \
    --output text
aurora-mysql

$ aws rds create-db-instance \
  --db-instance-identifier tpch100g-clone-instance \
  --db-cluster-identifier tpch100g-clone \
  --db-instance-class db.r5.4xlarge \
  --engine aurora-mysql

Memeriksa status dan mendapatkan detail klon

Anda dapat menggunakan perintah berikut untuk memeriksa status klaster DB kosong yang baru dibuat.

$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text

Atau Anda dapat memperoleh status dan nilai-nilai lain yang Anda butuhkan untuk membuat instance DB untuk klon Anda dengan menggunakan AWS CLI kueri berikut.

Untuk Linux, macOS, atau Unix:

aws rds describe-db-clusters --db-cluster-identifier my-clone \
  --query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'

Untuk Windows:

aws rds describe-db-clusters --db-cluster-identifier my-clone ^
  --query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"

Kueri ini menghasilkan output seperti yang berikut ini:

[
  {
        "Status": "available",
        "Engine": "aurora-mysql",
        "EngineVersion": "8.0.mysql_aurora.3.04.1",
        "EngineMode": "provisioned"
    }
]

Membuat instans DB Aurora untuk klon Anda

Gunakan perintah CLI create-db-instance untuk membuat instance DB untuk klon Anda atau yang disediakan. Aurora Serverless v2 Anda tidak membuat instance DB untuk Aurora Serverless v1 klon.

Instans DB mewarisi --master-username dan --master-user-password properti dari cluster DB sumber.

Contoh berikut membuat instance DB untuk klon yang disediakan.

Untuk Linux, macOS, atau Unix:

aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.r5.4xlarge \
    --engine aurora-mysql

Untuk Windows:

aws rds create-db-instance ^
    --db-instance-identifier my-new-db ^
    --db-cluster-identifier my-clone ^
    --db-instance-class db.r5.4xlarge ^
    --engine aurora-mysql

Parameter yang digunakan untuk kloning

Tabel berikut merangkum berbagai parameter yang digunakan dengan restore-db-cluster-to-point-in-time untuk mengkloning klaster DB Aurora.

Parameter Deskripsi

--source-db-cluster-identifier

Pilih parameter ini untuk menggunakan nama klaster DB Aurora sumber yang ingin Anda kloning.

--db-cluster-identifier

Pilih nama yang berarti untuk klon Anda saat Anda membuatnya dengan restore-db-cluster-to-point-in-time perintah. Kemudian, Anda meneruskan nama ini ke perintah create-db-instance.

--restore-type

Tentukan copy-on-write sebagai --restore-type untuk membuat klon klaster DB sumber dan bukan memulihkan klaster DB Aurora sumber.
--use-latest-restorable-time

Nilai ini menunjuk ke data volume terbaru yang dapat dipulihkan untuk cluster DB sumber. Gunakan untuk membuat klon.

--engine-mode

Gunakan parameter ini untuk membuat klon yang memiliki tipe berbeda dari cluster Aurora DB sumber, dengan salah satu nilai berikut:

  • Gunakan provisioned untuk membuat provisioned atau Aurora Serverless v2 clone dari cluster DB. Aurora Serverless v1

  • Gunakan serverless untuk membuat Aurora Serverless v1 klon dari cluster yang disediakan atau Aurora Serverless v2 DB.

    Saat Anda menentukan mode serverless mesin, Anda juga dapat memilih--scaling-configuration.

--scaling-configuration

Gunakan parameter ini untuk mengonfigurasi kapasitas minimum dan maksimum untuk Aurora Serverless v1 klon. Jika Anda tidak menentukan parameter ini, Aurora membuat klon menggunakan nilai kapasitas default untuk mesin DB.
--serverless-v2-scaling-configuration

Gunakan parameter ini untuk mengonfigurasi kapasitas minimum dan maksimum untuk Aurora Serverless v2 klon. Jika Anda tidak menentukan parameter ini, Aurora membuat klon menggunakan nilai kapasitas default untuk mesin DB.

Kloning silang VPC dengan Amazon Aurora

Misalkan Anda ingin memaksakan kontrol akses jaringan yang berbeda pada cluster asli dan klon. Misalnya, Anda dapat menggunakan kloning untuk membuat salinan klaster Aurora produksi di VPC yang berbeda untuk pengembangan dan pengujian. Atau Anda dapat membuat klon sebagai bagian dari migrasi dari subnet publik ke subnet pribadi, untuk meningkatkan keamanan database Anda.

Bagian berikut menunjukkan cara mengatur konfigurasi jaringan untuk klon sehingga cluster asli dan klon dapat mengakses node penyimpanan Aurora yang sama, bahkan dari subnet yang berbeda atau VPC yang berbeda. Memverifikasi sumber daya jaringan terlebih dahulu dapat menghindari kesalahan selama kloning yang mungkin sulit didiagnosis.

Jika Anda tidak terbiasa dengan bagaimana Aurora berinteraksi dengan VPC, subnet, dan grup subnet DB, lihat dulu. Amazon VPC dan Amazon Aurora Anda dapat mengerjakan tutorial di bagian itu untuk membuat sumber daya semacam ini di AWS konsol, dan memahami bagaimana mereka cocok bersama.

Karena langkah-langkahnya melibatkan peralihan antara layanan RDS dan EC2, contohnya menggunakan perintah AWS CLI untuk membantu Anda memahami cara mengotomatiskan operasi tersebut dan menyimpan output.

Sebelum Anda mulai

Sebelum Anda mulai menyiapkan klon lintas-VPC, pastikan untuk memiliki sumber daya berikut:

Mengumpulkan informasi tentang lingkungan jaringan

Dengan kloning lintas-VPC, lingkungan jaringan dapat berbeda secara substansional antara cluster asli dan klonnya. Sebelum Anda membuat klon, kumpulkan dan catat informasi tentang VPC, subnet, grup subnet DB, dan AZ yang digunakan di cluster asli. Dengan begitu, Anda dapat meminimalkan kemungkinan masalah. Jika masalah jaringan terjadi, Anda tidak perlu mengganggu aktivitas pemecahan masalah apa pun untuk mencari informasi diagnostik. Bagian berikut menunjukkan contoh CLI untuk mengumpulkan jenis informasi ini. Anda dapat menyimpan detail dalam format mana pun yang nyaman untuk dikonsultasikan saat membuat klon dan melakukan pemecahan masalah apa pun.

Langkah 1: Periksa Availability Zones dari cluster asli

Sebelum Anda membuat klon, verifikasi AZ mana yang digunakan cluster asli untuk penyimpanannya. Seperti dijelaskan dalamPenyimpanan dan keandalan Amazon Aurora, penyimpanan untuk setiap cluster Aurora dikaitkan dengan tepat tiga AZ. Karena Klaster DB Amazon Aurora mengambil keuntungan dari pemisahan komputasi dan penyimpanan, aturan ini benar terlepas dari berapa banyak instance dalam cluster.

Misalnya, jalankan perintah CLI seperti berikut ini, ganti nama cluster Anda sendiri. my_cluster Contoh berikut menghasilkan daftar yang diurutkan menurut abjad dengan nama AZ. 

aws rds describe-db-clusters \
  --db-cluster-identifier my_cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \
  --output text

Contoh berikut menunjukkan output sampel dari perintah sebelumnya. describe-db-clusters Ini menunjukkan bahwa penyimpanan untuk cluster Aurora selalu menggunakan tiga AZ. 

us-east-1c
us-east-1d
us-east-1e

Untuk membuat klon di lingkungan jaringan yang tidak memiliki semua sumber daya untuk terhubung ke AZ ini, Anda harus membuat subnet yang terkait dengan setidaknya dua AZ tersebut, dan kemudian membuat grup subnet DB yang berisi dua atau tiga subnet tersebut. Contoh berikut menunjukkan caranya.

Langkah 2: Periksa grup subnet DB dari cluster asli

Jika Anda ingin menggunakan jumlah subnet yang sama untuk klon seperti pada cluster asli, Anda bisa mendapatkan jumlah subnet dari grup subnet DB dari cluster asli. Grup subnet Aurora DB berisi setidaknya dua subnet, masing-masing terkait dengan AZ yang berbeda. Catat AZ mana yang terkait dengan subnet.

Contoh berikut menunjukkan bagaimana menemukan kelompok subnet DB dari cluster asli, dan kemudian bekerja mundur ke AZ yang sesuai. Gantikan nama cluster Anda my_cluster dengan perintah pertama. Gantikan nama grup subnet DB my_subnet dengan perintah kedua. 

aws rds describe-db-clusters --db-cluster-identifier my_cluster \
  --query '*[].DBSubnetGroup' --output text

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetAvailabilityZone.Name]' --output text

Output sampel mungkin terlihat mirip dengan berikut ini, untuk cluster dengan grup subnet DB yang berisi dua subnet. Dalam hal ini, two-subnets adalah nama yang ditentukan saat membuat grup subnet DB. 

two-subnets

us-east-1d
us-east-1c

Untuk cluster di mana grup subnet DB berisi tiga subnet, output mungkin terlihat mirip dengan berikut ini. 

three-subnets

us-east-1f
us-east-1d
us-east-1c

Langkah 3: Periksa subnet dari cluster asli

Jika Anda memerlukan detail lebih lanjut tentang subnet di cluster asli, jalankan perintah AWS CLI yang mirip dengan berikut ini. Anda dapat memeriksa atribut subnet seperti rentang alamat IP, pemilik, dan sebagainya. Dengan begitu, Anda dapat menentukan apakah akan menggunakan subnet yang berbeda di VPC yang sama, atau membuat subnet dengan karakteristik serupa di VPC yang berbeda.

Temukan ID subnet dari semua subnet yang tersedia di VPC Anda. 

aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc \
  --query '*[].[SubnetId]' --output text

Temukan subnet yang tepat digunakan dalam grup subnet DB Anda. 

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetIdentifier]' --output text

Kemudian tentukan subnet yang ingin Anda selidiki dalam daftar, seperti pada perintah berikut. Ganti nama subnet Anda untuk my_subnet_1 dan sebagainya. 

aws ec2 describe-subnets \
  --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'

Contoh berikut menunjukkan sebagian output dari describe-subnets perintah tersebut. Output menunjukkan beberapa atribut penting yang dapat Anda lihat untuk setiap subnet, seperti AZ terkait dan VPC yang menjadi bagiannya. 

{
    'Subnets': [
        {
            'AvailabilityZone': 'us-east-1d',
            'AvailableIpAddressCount': 54,
            'CidrBlock': '10.0.0.64/26',
            'State': 'available',
            'SubnetId': 'subnet-000a0bca00e0b0000',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...
        },
        {
            'AvailabilityZone': 'us-east-1c',
            'AvailableIpAddressCount': 55,
            'CidrBlock': '10.0.0.0/26',
            'State': 'available',
            'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...

Langkah 4: Periksa Availability Zones dari instans DB di cluster asli

Anda dapat menggunakan prosedur ini untuk memahami AZ yang digunakan untuk instance DB di cluster asli. Dengan begitu, Anda dapat mengatur AZ yang sama persis untuk instance DB di klon. Anda juga dapat menggunakan lebih banyak atau lebih sedikit instans DB di klon tergantung pada apakah klon digunakan untuk produksi, pengembangan dan pengujian, dan sebagainya.

Untuk setiap instance di cluster asli, jalankan perintah seperti berikut ini. Pastikan bahwa instance telah selesai dibuat dan berada dalam Available status terlebih dahulu. Gantikan pengenal instance untukmy_instance. 

aws rds describe-db-instances --db-instance-identifier my_instance \
  --query '*[].AvailabilityZone' --output text

Contoh berikut menunjukkan output dari menjalankan perintah sebelumnya. describe-db-instances Cluster Aurora memiliki empat instance database. Oleh karena itu, kami menjalankan perintah empat kali, mengganti pengidentifikasi instans DB yang berbeda setiap kali. Output menunjukkan bagaimana instans DB tersebut tersebar di maksimum tiga AZ. 

us-east-1a
us-east-1c
us-east-1d
us-east-1a

Setelah klon dibuat dan Anda menambahkan instance DB ke dalamnya, Anda dapat menentukan nama AZ yang sama ini dalam perintah. create-db-instance Anda dapat melakukannya untuk menyiapkan instance DB di cluster baru yang dikonfigurasi untuk AZ yang persis sama seperti di cluster asli.

Langkah 5: Periksa VPC yang dapat Anda gunakan untuk klon

Jika Anda bermaksud membuat klon di VPC yang berbeda dari aslinya, Anda bisa mendapatkan daftar ID VPC yang tersedia untuk akun Anda. Anda juga dapat melakukan langkah ini jika Anda perlu membuat subnet tambahan di VPC yang sama dengan cluster asli. Saat Anda menjalankan perintah untuk membuat subnet, Anda menentukan ID VPC sebagai parameter.

Untuk membuat daftar semua VPC untuk akun Anda, jalankan perintah CLI berikut: 

aws ec2 describe-vpcs --query '*[].[VpcId]' --output text

Contoh berikut menunjukkan output sampel dari perintah sebelumnya. describe-vpcs Output menunjukkan bahwa ada empat VPC di AWS akun saat ini yang dapat digunakan sebagai sumber atau tujuan untuk kloning lintas-VPC. 

vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad

Anda dapat menggunakan VPC yang sama dengan tujuan klon, atau VPC yang berbeda. Jika cluster asli dan klon berada di VPC yang sama, Anda dapat menggunakan kembali grup subnet DB yang sama untuk klon. Anda juga dapat membuat grup subnet DB yang berbeda. Misalnya, grup subnet DB baru mungkin menggunakan subnet pribadi, sedangkan grup subnet DB cluster asli mungkin menggunakan subnet publik. Jika Anda membuat klon di VPC yang berbeda, pastikan ada cukup subnet di VPC baru dan subnet terkait dengan AZ yang tepat dari cluster asli.

Membuat sumber daya jaringan untuk klon

Jika saat mengumpulkan informasi jaringan Anda menemukan bahwa sumber daya jaringan tambahan diperlukan untuk klon, Anda dapat membuat sumber daya tersebut sebelum mencoba mengatur klon. Misalnya, Anda mungkin perlu membuat lebih banyak subnet, subnet yang terkait dengan AZ tertentu, atau grup subnet DB baru.

Langkah 1: Buat subnet untuk klon

Jika Anda perlu membuat subnet baru untuk klon, jalankan perintah yang mirip dengan berikut ini. Anda mungkin perlu melakukan ini saat membuat klon di VPC yang berbeda, atau saat membuat beberapa perubahan jaringan lain seperti menggunakan subnet pribadi alih-alih subnet publik.

AWS secara otomatis menghasilkan ID subnet. Gantikan nama my_vpc VPC klon untuk. Pilih rentang alamat untuk --cidr-block opsi untuk mengizinkan setidaknya 16 alamat IP dalam rentang tersebut. Anda dapat menyertakan properti lain yang ingin Anda tentukan. Jalankan perintah aws ec2 create-subnet help untuk melihat semua pilihan. 

aws ec2 create-subnet --vpc-id my_vpc \
  --availability-zone AZ_name --cidr-block IP_range

Contoh berikut menunjukkan beberapa atribut penting dari subnet yang baru dibuat. 

{
    'Subnet': {
        'AvailabilityZone': 'us-east-1b',
        'AvailableIpAddressCount': 59,
        'CidrBlock': '10.0.0.64/26',
        'State': 'available',
        'SubnetId': 'subnet-44b4a44f4e44db444',
        'VpcId': 'vpc-555fc5df555e555dc',
        ...
        }
}

Langkah 2: Buat grup subnet DB untuk klon

Jika Anda membuat klon di VPC yang berbeda, atau kumpulan subnet yang berbeda dalam VPC yang sama, maka Anda membuat grup subnet DB baru dan menentukannya saat membuat klon.

Pastikan Anda mengetahui semua detail berikut. Anda dapat menemukan semua ini dari output dari contoh sebelumnya.

  1. VPC dari cluster asli. Untuk petunjuk, lihat Langkah 3: Periksa subnet dari cluster asli.

  2. VPC dari klon, jika Anda membuatnya di VPC yang berbeda. Untuk petunjuk, lihat Langkah 5: Periksa VPC yang dapat Anda gunakan untuk klon.

  3. Tiga AZ terkait dengan penyimpanan Aurora untuk cluster asli. Untuk petunjuk, lihat Langkah 1: Periksa Availability Zones dari cluster asli.

  4. Dua atau tiga AZ terkait dengan grup subnet DB untuk cluster asli. Untuk petunjuk, lihat Langkah 2: Periksa grup subnet DB dari cluster asli.

  5. ID subnet dan AZ terkait dari semua subnet di VPC yang ingin Anda gunakan untuk klon. Gunakan describe-subnets perintah yang sama seperti diLangkah 3: Periksa subnet dari cluster asli, menggantikan ID VPC dari VPC tujuan.

Periksa berapa banyak AZ yang terkait dengan penyimpanan cluster asli, dan terkait dengan subnet di VPC tujuan. Agar berhasil membuat klon, harus ada dua atau tiga AZ yang sama. Jika Anda memiliki kurang dari dua AZ yang sama, kembali keLangkah 1: Buat subnet untuk klon. Buat satu, dua, atau tiga subnet baru yang terkait dengan AZ yang terkait dengan penyimpanan cluster asli.

Pilih subnet di VPC tujuan yang terkait dengan AZ yang sama dengan penyimpanan Aurora di cluster aslinya. Idealnya, pilih tiga AZ. Melakukannya memberi Anda fleksibilitas paling besar untuk menyebarkan instans DB klon di beberapa AZ untuk ketersediaan sumber daya komputasi yang tinggi.

Jalankan perintah yang mirip dengan berikut ini untuk membuat grup subnet DB baru. Gantikan ID subnet Anda dalam daftar. Jika Anda menentukan ID subnet menggunakan variabel lingkungan, berhati-hatilah untuk mengutip daftar --subnet-ids parameter dengan cara yang mempertahankan tanda kutip ganda di sekitar ID. 

aws rds create-db-subnet-group --db-subnet-group-name my_subnet_group \
  --subnet-ids '["my_subnet_1","my_subnet_2","my_subnet3"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets for clone'

Contoh berikut menunjukkan output sebagian dari create-db-subnet-group perintah. 

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'my_subnet_group',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone',
        'VpcId': 'vpc-555fc5df555e555dc',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'my_subnet_1',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1c'
                },
                'SubnetStatus': 'Active'
            },
            {
                'SubnetIdentifier': 'my_subnet_2',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1d'
                },
                'SubnetStatus': 'Active'
            }
            ...
        ],
        'SupportedNetworkTypes': [
            'IPV4'
        ]
    }
}

Pada titik ini, Anda belum benar-benar membuat klon. Anda telah membuat semua sumber daya VPC dan subnet yang relevan sehingga Anda dapat menentukan parameter yang sesuai dengan create-db-instance perintah restore-db-cluster-to-point-in-time dan saat membuat klon.

Membuat klon Aurora dengan pengaturan jaringan baru

Setelah Anda memastikan bahwa konfigurasi VPC, subnet, AZ, dan grup subnet yang tepat tersedia untuk digunakan cluster baru, Anda dapat melakukan operasi kloning yang sebenarnya. Contoh CLI berikut menyoroti opsi seperti--db-subnet-group-name,--availability-zone, dan --vpc-security-group-ids yang Anda tentukan pada perintah untuk mengatur klon dan instance DB-nya.

Langkah 1: Tentukan grup subnet DB untuk klon

Saat Anda membuat klon, Anda dapat mengonfigurasi semua pengaturan VPC, subnet, dan AZ yang tepat dengan menentukan grup subnet DB. Gunakan perintah dalam contoh sebelumnya untuk memverifikasi semua hubungan dan pemetaan yang masuk ke grup subnet DB.

Misalnya, perintah berikut menunjukkan kloning cluster asli ke klon. Pada contoh pertama, cluster sumber dikaitkan dengan dua subnet dan klon dikaitkan dengan tiga subnet. Contoh kedua menunjukkan kasus sebaliknya, kloning dari cluster dengan tiga subnet ke cluster dengan dua subnet. 

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-3-subnets \
  --db-cluster-identifier cluster-cloned-to-2-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name two-subnets

Jika Anda bermaksud menggunakan instance Aurora Serverless v2 di klon, sertakan --serverless-v2-scaling-configuration opsi saat Anda membuat klon, seperti yang ditunjukkan. Melakukannya memungkinkan Anda menggunakan db.serverless kelas saat membuat instance DB di klon. Anda juga dapat memodifikasi klon nanti untuk menambahkan atribut konfigurasi penskalaan ini. Nomor kapasitas dalam contoh ini memungkinkan setiap instance v2 Tanpa Server di cluster untuk menskalakan antara 2 dan 32 Unit Kapasitas Aurora (ACU). Untuk informasi tentang fitur Aurora Serverless v2 dan cara memilih rentang kapasitas, lihat. Menggunakan Aurora Serverless v2 

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-2-subnets \
  --db-cluster-identifier cluster-cloned-to-3-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name three-subnets \
  --serverless-v2-scaling-configuration 'MinCapacity=2,MaxCapacity=32'

Terlepas dari jumlah subnet yang digunakan oleh instans DB, penyimpanan Aurora untuk cluster sumber dan klon dikaitkan dengan tiga AZ. Contoh berikut mencantumkan AZ yang terkait dengan cluster asli dan klon, untuk kedua restore-db-cluster-to-point-in-time perintah dalam contoh sebelumnya. 

aws rds describe-db-clusters --db-cluster-identifier cluster-with-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

Karena setidaknya dua AZ tumpang tindih antara setiap pasangan cluster asli dan klon, kedua cluster dapat mengakses penyimpanan Aurora dasar yang sama.

Langkah 2: Tentukan pengaturan jaringan untuk instance di klon

Saat Anda membuat instance DB di klon, secara default mereka mewarisi grup subnet DB dari cluster itu sendiri. Dengan begitu, Aurora secara otomatis menetapkan setiap instance ke subnet tertentu, dan membuatnya di AZ yang terkait dengan subnet. Pilihan ini nyaman, terutama untuk pengembangan dan pengujian sistem, karena Anda tidak perlu melacak ID subnet atau AZ sambil menambahkan instance baru ke klon.

Sebagai alternatif, Anda dapat menentukan AZ saat Anda membuat instance Aurora DB untuk klon. AZ yang Anda tentukan harus dari kumpulan AZ yang terkait dengan klon. Jika grup subnet DB yang Anda gunakan untuk klon hanya berisi dua subnet, maka Anda hanya dapat memilih dari AZ yang terkait dengan dua subnet tersebut. Pilihan ini menawarkan fleksibilitas dan ketahanan untuk sistem yang sangat tersedia, karena Anda dapat memastikan bahwa instance penulis dan instance pembaca siaga berada di AZ yang berbeda. Atau jika Anda menambahkan pembaca tambahan ke cluster, Anda dapat memastikan bahwa mereka tersebar di tiga AZ. Dengan begitu, bahkan dalam kasus kegagalan AZ yang jarang terjadi, Anda masih memiliki instance penulis dan instance pembaca lain di dua AZ lainnya.

Contoh berikut menambahkan instance DB yang disediakan ke klaster Aurora PostgreSQL kloning yang menggunakan grup subnet DB kustom. 

aws rds create-db-instance --db-cluster-identifier my_aurora_postgresql_clone \
  --db-instance-identifier my_postgres_instance \
  --db-subnet-group-name my_new_subnet \
  --engine aurora-postgresql \
  --db-instance-class db.t4g.medium

Contoh berikut menunjukkan sebagian output dari perintah tersebut. 

{
  'DBInstanceIdentifier': 'my_postgres_instance',
  'DBClusterIdentifier': 'my_aurora_postgresql_clone',
  'DBInstanceClass': 'db.t4g.medium',
  'DBInstanceStatus': 'creating'
  ...
}

Contoh berikut menambahkan instance Aurora Serverless v2 DB ke klon Aurora MySQL yang menggunakan grup subnet DB kustom. Untuk dapat menggunakan instance v2 Tanpa Server, pastikan untuk menentukan --serverless-v2-scaling-configuration opsi untuk restore-db-cluster-to-point-in-time perintah, seperti yang ditunjukkan pada contoh sebelumnya. 

aws rds create-db-instance --db-cluster-identifier my_aurora_mysql_clone \
  --db-instance-identifier my_mysql_instance \
  --db-subnet-group-name my_other_new_subnet \
  --engine aurora-mysql \
  --db-instance-class db.serverless

Contoh berikut menunjukkan sebagian output dari perintah tersebut. 

{
  'DBInstanceIdentifier': 'my_mysql_instance',
  'DBClusterIdentifier': 'my_aurora_mysql_clone',
  'DBInstanceClass': 'db.serverless',
  'DBInstanceStatus': 'creating'
  ...
}

Langkah 3: Membangun konektivitas dari sistem klien ke klon

Jika Anda sudah terhubung ke cluster Aurora dari sistem klien, Anda mungkin ingin mengizinkan jenis konektivitas yang sama ke klon baru. Misalnya, Anda mungkin tersambung ke cluster asli dari instans Amazon Cloud9 atau instans EC2. Untuk mengizinkan koneksi dari sistem klien yang sama, atau yang baru yang Anda buat di VPC tujuan, siapkan grup subnet DB yang setara dan grup keamanan VPC seperti di VPC. Kemudian tentukan grup subnet dan grup keamanan saat Anda membuat klon.

Contoh berikut menyiapkan klon Aurora Serverless v2. Konfigurasi itu didasarkan pada kombinasi --engine-mode provisioned dan --serverless-v2-scaling-configuration saat membuat cluster DB, dan kemudian --db-instance-class db.serverless saat membuat setiap instans DB di cluster. Mode provisioned mesin adalah default, sehingga Anda dapat menghilangkan opsi itu jika Anda mau. 

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier serverless-sql-postgres\
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-subnet-group-name 'default-vpc-1234' \
  --vpc-security-group-ids 'sg-4567' \
  --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \
  --restore-type copy-on-write \
  --use-latest-restorable-time

Kemudian, saat membuat instance DB di klon, tentukan opsi yang sama--db-subnet-group-name. Secara opsional, Anda dapat menyertakan --availability-zone opsi dan menentukan salah satu AZ yang terkait dengan subnet di grup subnet tersebut. AZ itu juga harus menjadi salah satu AZ yang terkait dengan cluster asli. 

aws rds create-db-instance \
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-instance-identifier serverless-sql-postgres-clone-instance \
  --db-instance-class db.serverless \
  --db-subnet-group-name 'default-vpc-987zyx654' \
  --availability-zone 'us-east-1c' \
  --engine aurora-postgresql

Memindahkan cluster dari subnet publik ke subnet pribadi

Anda dapat menggunakan kloning untuk memigrasikan klaster antara subnet publik dan pribadi. Anda dapat melakukan ini saat menambahkan lapisan keamanan tambahan ke aplikasi Anda sebelum menerapkannya ke produksi. Untuk contoh ini, Anda seharusnya sudah menyiapkan subnet pribadi dan gateway NAT sebelum memulai proses kloning dengan Aurora.

Untuk langkah-langkah yang melibatkan Aurora, Anda dapat mengikuti langkah-langkah umum yang sama seperti pada contoh sebelumnya untuk dan. Mengumpulkan informasi tentang lingkungan jaringan Membuat klon Aurora dengan pengaturan jaringan baru Perbedaan utama adalah bahwa bahkan jika Anda memiliki subnet publik yang memetakan ke semua AZ dari cluster asli, sekarang Anda harus memverifikasi bahwa Anda memiliki cukup subnet pribadi untuk cluster Aurora, dan bahwa subnet tersebut terkait dengan semua AZ yang sama yang digunakan untuk penyimpanan Aurora di cluster asli. Mirip dengan kasus penggunaan kloning lainnya, Anda dapat membuat grup subnet DB untuk klon dengan tiga atau dua subnet pribadi yang terkait dengan AZ yang diperlukan. Namun, jika Anda menggunakan dua subnet pribadi di grup subnet DB, Anda harus memiliki subnet pribadi ketiga yang terkait dengan AZ ketiga yang digunakan untuk penyimpanan Aurora di cluster asli.

Anda dapat berkonsultasi dengan daftar periksa ini untuk memverifikasi bahwa semua persyaratan ada untuk melakukan operasi kloning jenis ini.

Ketika semua prasyarat sudah ada, Anda dapat menjeda aktivitas database pada cluster asli saat Anda membuat klon dan mengalihkan aplikasi Anda untuk menggunakannya. Setelah klon dibuat dan Anda memverifikasi bahwa Anda dapat terhubung ke sana, menjalankan kode aplikasi Anda, dan sebagainya, Anda dapat menghentikan penggunaan cluster asli.

nd-to-end Contoh E membuat klon lintas-VPC

Membuat klon di VPC yang berbeda dari aslinya menggunakan langkah-langkah umum yang sama seperti pada contoh sebelumnya. Karena ID VPC adalah properti dari subnet, Anda tidak benar-benar menentukan ID VPC sebagai parameter saat menjalankan salah satu perintah RDS CLI. Perbedaan utamanya adalah Anda lebih mungkin perlu membuat subnet baru, subnet baru yang dipetakan ke AZ tertentu, grup keamanan VPC, dan grup subnet DB baru. Itu terutama benar jika ini adalah cluster Aurora pertama yang Anda buat di VPC itu.

Anda dapat berkonsultasi dengan daftar periksa ini untuk memverifikasi bahwa semua persyaratan ada untuk melakukan operasi kloning jenis ini.

Ketika semua prasyarat sudah ada, Anda dapat menjeda aktivitas database pada cluster asli saat Anda membuat klon dan mengalihkan aplikasi Anda untuk menggunakannya. Setelah klon dibuat dan Anda memverifikasi bahwa Anda dapat terhubung ke sana, menjalankan kode aplikasi Anda, dan sebagainya, Anda dapat mempertimbangkan apakah akan menjaga kedua asli dan klon berjalan, atau menghentikan penggunaan cluster asli.

Contoh Linux berikut menunjukkan urutan operasi AWS CLI untuk mengkloning cluster Aurora DB dari satu VPC ke VPC lainnya. Beberapa bidang yang tidak relevan dengan contoh tidak ditampilkan dalam output perintah.

Pertama, kami memeriksa ID VPC sumber dan tujuan. Nama deskriptif yang Anda tetapkan ke VPC saat Anda membuatnya direpresentasikan sebagai tag dalam metadata VPC. 

$ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]'
[
    [
        'vpc-0f0c0fc0000b0ffb0',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-source'
            }
        ]
    ],
    [
        'vpc-9e99d9f99a999bd99',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-dest'
            }
        ]
    ]
]

Cluster asli sudah ada di VPC sumber. Untuk mengatur klon menggunakan set AZ yang sama untuk penyimpanan Aurora, kami memeriksa AZ yang digunakan oleh cluster asli. 

$ aws rds describe-db-clusters --db-cluster-identifier original-cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

Kami memastikan ada subnet yang sesuai dengan AZ yang digunakan oleh cluster asli:us-east-1c,us-east-1d, dan. us-east-1f 

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
  --availability-zone us-east-1c --cidr-block 10.0.0.128/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1c',
        'SubnetId': 'subnet-3333a33be3ef3e333',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1d --cidr-block 10.0.0.160/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1d',
        'SubnetId': 'subnet-4eeb444cd44b4d444',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1f --cidr-block 10.0.0.224/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1f',
        'SubnetId': 'subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

Contoh ini menegaskan bahwa ada subnet yang memetakan ke AZ yang diperlukan di VPC tujuan. 

aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] |
[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table

---------------------------------------------------------------------------
|                             DescribeSubnets                             |
+------------------+----------------------------+-------------------------+
| AvailabilityZone |         SubnetId           |          VpcId          |
+------------------+----------------------------+-------------------------+
|  us-east-1a      |  subnet-000ff0e00000c0aea  |  vpc-9e99d9f99a999bd99  |
|  us-east-1b      |  subnet-1111d111111ca11b1  |  vpc-9e99d9f99a999bd99  |
|  us-east-1c      | subnet-3333a33be3ef3e333   |  vpc-9e99d9f99a999bd99  |
|  us-east-1d      | subnet-4eeb444cd44b4d444   |  vpc-9e99d9f99a999bd99  |
|  us-east-1f      | subnet-66eea6666fb66d66c   |  vpc-9e99d9f99a999bd99  |
+------------------+----------------------------+-------------------------+

Sebelum membuat cluster Aurora DB di VPC, Anda harus memiliki grup subnet DB dengan subnet yang memetakan ke AZ yang digunakan untuk penyimpanan Aurora. Saat Anda membuat cluster biasa, Anda dapat menggunakan set tiga AZ apa pun. Saat Anda mengkloning cluster yang ada, grup subnet harus cocok setidaknya dua dari tiga AZ yang digunakannya untuk penyimpanan Aurora. 

$ aws rds create-db-subnet-group \
  --db-subnet-group-name subnet-group-in-other-vpc \
  --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c'

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'subnet-group-in-other-vpc',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'subnet-4eeb444cd44b4d444',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }
            },
            {
                'SubnetIdentifier': 'subnet-3333a33be3ef3e333',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }
            },
            {
                'SubnetIdentifier': 'subnet-66eea6666fb66d66c',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1f' }
            }
        ]
    }
}

Sekarang subnet dan grup subnet DB sudah ada. Contoh berikut menunjukkan restore-db-cluster-to-point-in-time yang mengkloning cluster. --db-subnet-group-nameOpsi ini mengaitkan klon dengan kumpulan subnet yang benar yang memetakan ke set AZ yang benar dari cluster asli. 

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier original-cluster \
  --db-cluster-identifier clone-in-other-vpc \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name subnet-group-in-other-vpc

{
  'DBClusterIdentifier': 'clone-in-other-vpc',
  'DBSubnetGroup': 'subnet-group-in-other-vpc',
  'Engine': 'aurora-postgresql',
  'EngineVersion': '15.4',
  'Status': 'creating',
  'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com'
}

Contoh berikut menegaskan bahwa penyimpanan Aurora di klon menggunakan set AZ yang sama seperti di cluster asli. 

$ aws rds describe-db-clusters --db-cluster-identifier clone-in-other-vpc \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

Pada titik ini, Anda dapat membuat instance DB untuk klon. Pastikan bahwa grup keamanan VPC yang terkait dengan setiap instance memungkinkan koneksi dari rentang alamat IP yang Anda gunakan untuk instans EC2, server aplikasi, dan sebagainya yang ada di VPC tujuan.

Kloning lintas akun dengan AWS RAM dan Amazon Aurora

Dengan menggunakan AWS Resource Access Manager (AWS RAM) dengan Amazon Aurora, Anda dapat berbagi klaster Aurora DB dan klon milik akun Anda dengan AWS akun atau organisasi lain. AWS Kloning lintas akun lebih cepat daripada membuat dan memulihkan snapshot basis data. Anda dapat membuat klon dari salah satu klaster DB Aurora Anda lalu membagikan klon tersebut. Atau Anda dapat membagikan cluster Aurora DB Anda dengan AWS akun lain dan membiarkan pemegang akun membuat klon. Pendekatan yang Anda pilih tergantung pada kasus penggunaan Anda.

Misalnya, Anda mungkin perlu berbagi klon basis data keuangan Anda secara rutin dengan tim audit internal organisasi Anda. Dalam hal ini, tim audit Anda memiliki akun AWS untuk aplikasi yang digunakannya. Anda dapat memberikan izin kepada AWS akun tim audit untuk mengakses klaster Aurora DB Anda dan mengkloningnya sesuai kebutuhan.

Di sisi lain, jika vendor luar mengaudit data keuangan Anda, Anda mungkin lebih memilih untuk membuat klon sendiri. Anda kemudian memberi vendor luar tersebut akses ke klon saja.

Anda juga dapat menggunakan kloning lintas akun untuk mendukung banyak kasus penggunaan yang sama untuk kloning dalam AWS akun yang sama, seperti pengembangan dan pengujian. Misalnya, organisasi Anda mungkin menggunakan AWS akun yang berbeda untuk produksi, pengembangan, pengujian, dan sebagainya. Untuk informasi selengkapnya, lihat Gambaran umum kloning Aurora.

Dengan demikian, Anda mungkin ingin berbagi klon dengan AWS akun lain atau mengizinkan akun lain untuk membuat klon dari cluster Aurora DB Anda. AWS Dalam kedua kasus, mulailah dengan menggunakan AWS RAM untuk membuat objek berbagi. Untuk informasi lengkap tentang berbagi AWS sumber daya antar AWS akun, lihat Panduan AWS RAM Pengguna.

Membuat klon lintas akun memerlukan tindakan dari AWS akun yang memiliki cluster asli, dan AWS akun yang membuat klon. Pertama, pemilik klaster asli memodifikasi klaster untuk mengizinkan satu atau beberapa akun lain mengkloningnya. Jika salah satu akun berada di AWS organisasi yang berbeda AWS , buat undangan berbagi. Akun lain tersebut harus menerima undangan sebelum melanjutkan. Kemudian, setiap akun terotorisasi dapat mengkloning klaster. Selama proses ini, klaster diidentifikasi berdasarkan Amazon Resource Name (ARN) yang unik.

Seperti halnya kloning dalam AWS akun yang sama, ruang penyimpanan tambahan hanya digunakan jika perubahan dilakukan pada data oleh sumber atau klon. Biaya untuk penyimpanan kemudian diterapkan pada waktu itu. Jika klaster sumber dihapus, biaya penyimpanan didistribusikan secara merata di antara klon yang tersisa.

Batasan kloning lintas akun

Kloning lintas akun Aurora memiliki batasan sebagai berikut:

  • Anda tidak dapat mengkloning Aurora Serverless v1 cluster di seluruh AWS akun.

  • Anda tidak dapat melihat atau menerima undangan ke sumber daya bersama dengan. AWS Management Console Gunakan API Amazon RDS, atau AWS RAM konsol untuk melihat dan menerima undangan ke sumber daya bersama. AWS CLI

  • Anda hanya dapat membuat satu klon baru dari klon yang telah dibagikan dengan akun Anda AWS .

  • Anda tidak dapat berbagi sumber daya (klon atau klaster Aurora DB) yang telah dibagikan dengan akun Anda. AWS

  • Anda dapat membuat maksimum 15 klon lintas akun dari setiap klaster DB Aurora.

  • Masing-masing dari 15 klon lintas akun harus dimiliki oleh akun yang berbeda AWS . Artinya, Anda hanya dapat membuat satu klon lintas akun dari sebuah cluster dalam akun apa pun AWS .

  • Setelah Anda mengkloning klaster, klaster asli dan klonnya dianggap sama untuk tujuan memberlakukan batasan pada klon lintas akun. Anda tidak dapat membuat klon lintas akun dari klaster asli dan kloning kloning dalam akun yang sama. AWS Jumlah total klon lintas akun untuk klaster asli dan klonnya tidak boleh melebihi 15.

  • Anda tidak dapat berbagi cluster Aurora DB dengan AWS akun lain kecuali klaster dalam keadaan. ACTIVE

  • Anda tidak dapat mengganti nama cluster Aurora DB yang telah dibagikan dengan AWS akun lain.

  • Anda tidak dapat membuat klon lintas akun dari klaster yang dienkripsikan dengan kunci RDS default.

  • Anda tidak dapat membuat klon yang tidak terenkripsi dalam satu akun AWS dari kluster Aurora DB terenkripsi yang telah dibagikan oleh akun lain. AWS Pemilik klaster harus memberikan izin untuk mengakses AWS KMS key klaster sumber. Namun, Anda dapat menggunakan kunci yang berbeda saat Anda membuat klon.

Mengizinkan AWS akun lain untuk mengkloning klaster Anda

Untuk mengizinkan AWS akun lain mengkloning klaster yang Anda miliki, gunakan AWS RAM untuk mengatur izin berbagi. Melakukannya juga mengirimkan undangan ke masing-masing akun lain yang ada di AWS organisasi yang berbeda.

Untuk prosedur berbagi sumber daya yang Anda miliki di AWS RAM konsol, lihat Berbagi sumber daya yang Anda miliki di Panduan AWS RAM Pengguna.

Memberikan izin ke AWS akun lain untuk mengkloning klaster Anda

Jika klaster yang Anda bagikan dienkripsi, Anda juga berbagi AWS KMS key untuk klaster tersebut. Anda dapat mengizinkan pengguna atau peran AWS Identity and Access Management (IAM) dalam satu AWS akun untuk menggunakan kunci KMS di akun yang berbeda.

Untuk melakukan ini, pertama-tama Anda menambahkan akun eksternal (pengguna root) ke kebijakan kunci kunci KMS melalui AWS KMS. Anda tidak menambahkan pengguna atau peran individual ke kebijakan kunci, hanya akun eksternal yang memilikinya. Anda hanya dapat berbagi kunci KMS yang Anda buat, bukan kunci layanan RDS default. Untuk informasi tentang kontrol akses untuk kunci KMS, lihat Autentikasi dan kontrol akses untuk AWS KMS.

Untuk memberikan izin untuk mengkloning klaster Anda

  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Basis Data.

  3. Pilih klaster DB yang ingin Anda bagikan untuk melihat halaman Detail, lalu pilih tab Konektivitas & keamanan.

  4. Di bagian Share DB cluster with other AWS accounts, masukkan ID akun numerik untuk AWS akun yang ingin Anda izinkan untuk mengkloning cluster ini. Untuk ID akun dalam organisasi yang sama, Anda dapat mulai mengetik di kotak, kemudian memilih dari menu.

    penting

    Dalam beberapa kasus, Anda mungkin ingin akun yang tidak berada dalam organisasi AWS yang sama dengan akun Anda untuk mengkloning klaster. Dalam kasus ini, demi alasan keamanan, konsol tidak melaporkan siapa yang memiliki ID akun tersebut atau apakah akun tersebut ada.

    Hati-hati memasukkan nomor akun yang tidak berada di AWS organisasi yang sama dengan AWS akun Anda. Segera verifikasi bahwa Anda berbagi kepada akun yang dimaksud.

  5. Di halaman konfirmasi, verifikasi bahwa ID akun yang Anda tentukan sudah benar. Masukkan share di kotak konfirmasi untuk mengonfirmasi.

    Pada halaman Detail, muncul entri yang menunjukkan ID AWS akun yang ditentukan di bawah Akun tempat cluster DB ini dibagikan. Kolom Status awalnya menunjukkan status Tertunda.

  6. Hubungi pemilik AWS akun lain, atau masuk ke akun itu jika Anda memiliki keduanya. Minta pemilik akun lain untuk menerima undangan berbagi dan mengkloning klaster DB, sebagaimana dijelaskan sebagai berikut.

Untuk memberikan izin untuk mengkloning klaster Anda

  1. Kumpulkan informasi untuk parameter yang diperlukan. Anda memerlukan ARN untuk cluster Anda dan ID numerik untuk akun lainnya. AWS

  2. Jalankan AWS RAM perintah CLI. create-resource-share

    Untuk Linux, macOS, atau Unix:

    aws ram create-resource-share --name descriptive_name \
  --region region \
  --resource-arns cluster_arn \
  --principals other_account_ids

    Untuk Windows:

    aws ram create-resource-share --name descriptive_name ^
  --region region ^
  --resource-arns cluster_arn ^
  --principals other_account_ids

    Untuk menyertakan banyak ID akun untuk parameter --principals, pisahkan ID dari satu sama lainnya dengan spasi. Untuk menentukan apakah akun AWS yang diizinkan bisa berada di luar organisasi Anda, termasuk parameter --allow-external-principals atau --no-allow-external-principals untuk create-resource-share.

Untuk memberikan izin untuk mengkloning klaster Anda

  1. Kumpulkan informasi untuk parameter yang diperlukan. Anda memerlukan ARN untuk cluster Anda dan ID numerik untuk akun lainnya. AWS

  2. Panggil operasi AWS RAM API CreateResourceBagikan, dan tentukan nilai berikut:

    • Tentukan ID akun untuk satu atau lebih AWS akun sebagai principals parameter.

    • Tentukan ARN untuk satu atau beberapa klaster DB Aurora sebagai parameter resourceArns.

    • Tentukan apakah ID akun yang diizinkan bisa berada di luar organisasi AWS Anda atau tidak dengan menyertakan nilai Boolean untuk parameter allowExternalPrincipals.

Membuat ulang klaster yang menggunakan kunci RDS default

Jika klaster terenkripsi yang ingin Anda bagikan menggunakan kunci RDS default, pastikan untuk membuat ulang klaster tersebut. Untuk melakukannya, buat snapshot manual dari klaster DB Anda, gunakan AWS KMS key, lalu pulihkan klaster tersebut ke klaster baru. Kemudian, bagikan klaster baru ini. Untuk melakukan proses ini, lakukan langkah-langkah berikut.

Untuk membuat ulang klaster terenkripsi yang menggunakan kunci RDS default

  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Pilih Snapshot dari panel navigasi.

  3. Pilih snapshot Anda.

  4. Untuk Tindakan, pilih Salin Snapshot, lalu pilih Aktifkan enkripsi.

  5. Untuk AWS KMS key, pilih kunci enkripsi baru yang ingin Anda gunakan.

  6. Pulihkan snapshot yang telah disalin. Untuk melakukannya, ikuti prosedur dalam Memulihkan dari snapshot klaster DB. Instans DB baru akan menggunakan kunci enkripsi baru Anda.

  7. (Opsional) Hapus klaster DB lama jika Anda tidak lagi membutuhkannya. Untuk melakukannya, ikuti prosedur dalam Menghapus snapshot klaster DB. Sebelum Anda melakukannya, konfirmasi bahwa klaster baru Anda memiliki semua data yang diperlukan dan bahwa aplikasi Anda dapat mengaksesnya dengan sukses.

Memeriksa apakah klaster yang Anda miliki dibagikan dengan AWS akun lain

Anda dapat memeriksa apakah pengguna lain memiliki izin untuk berbagi klaster. Tindakan tersebut dapat membantu Anda memahami apakah klaster hampir mencapai batas jumlah maksimum klon lintas akun.

Untuk prosedur berbagi sumber daya menggunakan AWS RAM konsol, lihat Berbagi sumber daya yang Anda miliki di Panduan AWS RAM Pengguna.

Untuk mengetahui apakah klaster yang Anda miliki dibagikan dengan AWS akun lain

  • Panggil perintah AWS RAM CLI list-principals, menggunakan ID akun Anda sebagai pemilik sumber daya dan ARN cluster Anda sebagai ARN sumber daya. Anda dapat melihat semua pembagian dengan perintah berikut. Hasilnya menunjukkan AWS akun mana yang diizinkan untuk mengkloning cluster. 

    aws ram list-principals \
    --resource-arns your_cluster_arn \
    --principals your_aws_id
Untuk mengetahui apakah klaster yang Anda miliki dibagikan dengan AWS akun lain

  • Panggil operasi AWS RAM API ListPrincipals. Gunakan ID akun Anda sebagai pemilik sumber daya dan ARN klaster sebagai ARN sumber daya.

Kloning cluster yang dimiliki oleh akun lain AWS

Untuk mengkloning cluster yang dimiliki oleh AWS akun lain, gunakan AWS RAM untuk mendapatkan izin untuk membuat klon. Setelah Anda mendapatkan izin yang diperlukan, gunakan prosedur standar untuk mengkloning klaster Aurora.

Anda juga dapat memeriksa apakah cluster yang Anda miliki adalah tiruan dari cluster yang dimiliki oleh AWS akun yang berbeda.

Untuk prosedur untuk bekerja dengan sumber daya yang dimiliki oleh orang lain di AWS RAM konsol, lihat Mengakses sumber daya yang dibagikan dengan Anda di Panduan AWS RAM Pengguna.

Melihat undangan untuk mengkloning cluster yang dimiliki oleh akun lain AWS

Untuk bekerja dengan undangan untuk mengkloning cluster yang dimiliki oleh AWS akun di AWS organisasi lain, gunakan, AWS RAM konsol AWS CLI, atau API. AWS RAM Saat ini, Anda tidak dapat melakukan prosedur ini menggunakan konsol Amazon RDS.

Untuk prosedur untuk bekerja dengan undangan di AWS RAM konsol, lihat Mengakses sumber daya yang dibagikan dengan Anda di Panduan Pengguna.AWS RAM

Untuk melihat undangan untuk mengkloning cluster yang dimiliki oleh akun lain AWS

  1. Jalankan AWS RAM perintah CLI. get-resource-share-invitations 

    aws ram get-resource-share-invitations --region region_name

    Hasil dari perintah sebelumnya menunjukkan semua undangan untuk klaster klon, termasuk semua yang telah Anda terima atau ditolak.

  2. (Opsional) Filter daftar sehingga Anda hanya melihat undangan yang memerlukan tindakan dari Anda. Untuk melakukannya, tambahkan parameter --query 'resourceShareInvitations[?status==`PENDING`]'.

Untuk melihat undangan untuk mengkloning cluster yang dimiliki oleh akun lain AWS

  1. Panggil operasi AWS RAM API GetResourceShareInvitations. Operasi ini akan menampilkan semua undangan tersebut, termasuk semua yang telah Anda terima atau tolak.

  2. (Opsional) Temukan hanya undangan yang memerlukan tindakan dari Anda dengan memeriksa status dengan nilai PENDING pada bidang resourceShareAssociations yang dihasilkan.

Menerima undangan untuk berbagi cluster yang dimiliki oleh akun lain AWS

Anda dapat menerima undangan untuk berbagi cluster yang dimiliki oleh AWS akun lain yang berada di organisasi yang berbeda. AWS Untuk bekerja dengan undangan ini, gunakan API AWS CLI, the AWS RAM and RDS, atau konsol. AWS RAM Saat ini, Anda tidak dapat melakukan prosedur ini menggunakan konsol RDS.

Untuk prosedur untuk bekerja dengan undangan di AWS RAM konsol, lihat Mengakses sumber daya yang dibagikan dengan Anda di Panduan Pengguna.AWS RAM

Untuk menerima undangan untuk berbagi klaster dari AWS akun lain

  1. Temukan ARN undangan dengan menjalankan perintah AWS RAM CLI get-resource-share-invitations, seperti yang ditunjukkan sebelumnya.

  2. Terima undangan dengan memanggil perintah AWS RAM CLI accept-resource-share-invitation, seperti yang ditunjukkan berikut.

    Untuk Linux, macOS, atau Unix:

    aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn invitation_arn \
  --region region

    Untuk Windows:

    aws ram accept-resource-share-invitation ^
  --resource-share-invitation-arn invitation_arn ^
  --region region
Untuk menerima undangan untuk membagikan klaster orang lain

  1. Temukan ARN undangan dengan memanggil operasi AWS RAM API GetResourceShareInvitations, seperti yang ditunjukkan sebelumnya.

  2. Berikan ARN itu sebagai resourceShareInvitationArn parameter ke operasi RDS API. AcceptResourceShareInvitation

Kloning cluster Aurora yang dimiliki oleh akun lain AWS

Setelah Anda menerima undangan dari AWS akun yang memiliki cluster DB, seperti yang ditunjukkan sebelumnya, Anda dapat mengkloning cluster.

Untuk mengkloning cluster Aurora yang dimiliki oleh akun lain AWS

  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Basis data.

    Di bagian atas daftar basis data, Anda akan melihat satu atau beberapa item dengan nilai Peran yang menampilkan Shared from account #account_id. Untuk alasan keamanan, Anda hanya dapat melihat informasi terbatas tentang klaster asli. Properti yang dapat Anda lihat antara lain adalah mesin dan versi basis data, yang harus sama dalam kloning klaster Anda.

  3. Pilih klaster yang akan dikloning.

  4. Untuk Tindakan, pilih Buat klon.

  5. Ikuti prosedur dalam Konsol untuk menyelesaikan penyiapan klaster yang dikloning.

  6. Sesuai kebutuhan, aktifkan enkripsi untuk klaster yang dikloning. Jika klaster tersebut dienkripsi, Anda harus mengaktifkan enkripsi untuk klaster yang dikloning. Akun AWS yang berbagi klaster dengan Anda juga harus berbagi kunci KMS yang digunakan untuk mengenkripsi klaster. Anda dapat menggunakan kunci KMS yang sama untuk mengenkripsi klon, atau kunci KMS Anda sendiri. Anda tidak dapat membuat klon lintas akun untuk klaster yang dienkripsi dengan kunci KMS default.

    Akun yang memiliki kunci enkripsi harus memberikan izin penggunaan kunci tersebut ke akun tujuan melalui kebijakan kunci. Proses ini serupa dengan cara berbagi snapshot terenkripsi, dengan menggunakan kebijakan kunci yang memberikan izin ke akun tujuan untuk menggunakan kunci.

Untuk mengkloning cluster Aurora yang dimiliki oleh akun lain AWS

  1. Terima undangan dari AWS akun yang memiliki cluster DB, seperti yang ditunjukkan sebelumnya.

  2. Kloning klaster dengan menentukan ARN lengkap klaster sumber dalam parameter source-db-cluster-identifier pada perintah CLI RDS restore-db-cluster-to-point-in-time, sebagaimana ditunjukkan berikut ini.

    Jika ARN yang diteruskan sebagai source-db-cluster-identifier belum dibagikan, kesalahan yang sama akan ditampilkan seolah-olah klaster tersebut tidak ada.

    Untuk Linux, macOS, atau Unix:

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time

    Untuk Windows:

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time

  3. Jika klaster yang Anda kloning terenkripsi, enkripsi klaster yang dikloning dengan menyertakan parameter kms-key-id. Nilai kms-key-id ini dapat sama dengan yang digunakan untuk mengenkripsi klaster DB asli, atau kunci KMS Anda sendiri. Akun Anda harus memiliki izin untuk menggunakan kunci enkripsi tersebut.

    Untuk Linux, macOS, atau Unix:

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time \
  --kms-key-id=arn:aws:kms:arn_details

    Untuk Windows:

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time ^
  --kms-key-id=arn:aws:kms:arn_details

    Akun yang memiliki kunci enkripsi harus memberikan izin penggunaan kunci tersebut ke akun tujuan melalui kebijakan kunci. Proses ini serupa dengan cara berbagi snapshot terenkripsi, dengan menggunakan kebijakan kunci yang memberikan izin ke akun tujuan untuk menggunakan kunci. Contoh kebijakan kunci adalah sebagai berikut. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
catatan

Perintah CLI restore-db-cluster-to-point-in-time AWS hanya memulihkan klaster DB, bukan instans DB untuk klaster tersebut. Untuk membuat instans DB untuk klaster DB yang dipulihkan, invokasi perintah create-db-instance. Tentukan pengidentifikasi klaster DB yang dipulihkan di --db-cluster-identifier.

Anda dapat membuat instans DB hanya setelah perintah restore-db-cluster-to-point-in-time selesai dan klaster DB tersedia.

Untuk mengkloning cluster Aurora yang dimiliki oleh akun lain AWS

  1. Terima undangan dari AWS akun yang memiliki cluster DB, seperti yang ditunjukkan sebelumnya.

  2. Kloning klaster dengan menentukan ARN lengkah klaster sumber dalam parameter SourceDBClusterIdentifier pada operasi API RDS RestoreDBClusterToPointInTime.

    Jika ARN yang diteruskan sebagai SourceDBClusterIdentifier belum dibagikan, kesalahan yang sama akan ditampilkan seolah-olah klaster tersebut tidak ada.

  3. Jika klaster yang Anda kloning terenkripsi, sertakan parameter KmsKeyId untuk mengenkripsi klaster yang dikloning. Nilai kms-key-id ini dapat sama dengan yang digunakan untuk mengenkripsi klaster DB asli, atau kunci KMS Anda sendiri. Akun Anda harus memiliki izin untuk menggunakan kunci enkripsi tersebut.

    Saat mengkloning volume, akun tujuan harus memiliki izin untuk menggunakan kunci enkripsi yang digunakan untuk mengenkripsi klaster sumber. Aurora mengenkripsi klaster baru yang dikloning dengan kunci enkripsi yang ditentukan dalam KmsKeyId.

    Akun yang memiliki kunci enkripsi harus memberikan izin penggunaan kunci tersebut ke akun tujuan melalui kebijakan kunci. Proses ini serupa dengan cara berbagi snapshot terenkripsi, dengan menggunakan kebijakan kunci yang memberikan izin ke akun tujuan untuk menggunakan kunci. Contoh kebijakan kunci adalah sebagai berikut. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
catatan

Operasi RestoreDB ClusterTo PointIn Time RDS API hanya mengembalikan cluster DB, bukan instance DB untuk cluster DB tersebut. Untuk membuat instans DB untuk klaster DB yang dipulihkan, invokasi operasi API RDS CreateDBInstance. Tentukan pengidentifikasi klaster DB yang dipulihkan di DBClusterIdentifier. Anda dapat membuat instans DB hanya setelah operasi RestoreDBClusterToPointInTime selesai dan klaster DB tersedia.

Memeriksa apakah klaster DB merupakan klon lintas akun

Objek DBClusters mengidentifikasi apakah setiap klaster merupakan klon lintas akun. Anda dapat melihat klaster yang izin kloning Anda miliki dengan menggunakan opsi include-shared saat Anda menjalankan perintah CLI RDS describe-db-clusters. Namun, Anda tidak dapat melihat sebagian besar detail konfigurasi untuk klaster tersebut.

Untuk memeriksa apakah klaster DB merupakan klon lintas akun

  • Panggil perintah CLI RDS describe-db-clusters.

    Contoh berikut menunjukkan bagaimana klaster DB klon lintas akun yang sebenarnya atau potensial muncul di output describe-db-clusters. Untuk klaster yang ada yang dimiliki oleh AWS akun Anda, CrossAccountClone bidang menunjukkan apakah klaster adalah tiruan dari cluster DB yang dimiliki oleh akun lain AWS .

    Dalam beberapa kasus, entri mungkin memiliki nomor AWS akun yang berbeda dari milik Anda di DBClusterArn lapangan. Dalam hal ini, entri itu mewakili cluster yang dimiliki oleh AWS akun yang berbeda dan Anda dapat mengkloning. Entri tersebut memiliki beberapa bidang selain DBClusterArn. Saat membuat klaster yang diklon, tentukan nilai StorageEncrypted, Engine, dan EngineVersion yang sama seperti dalam klaster asli. 

    $aws rds describe-db-clusters --include-shared --region us-east-1
{
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0
  ]
}
Untuk memeriksa apakah klaster DB merupakan klon lintas akun

  • Panggil operasi API RDS DescribeDBClusters.

    Untuk klaster yang ada yang dimiliki oleh AWS akun Anda, CrossAccountClone bidang menunjukkan apakah klaster adalah tiruan dari klaster DB yang dimiliki oleh akun lain AWS . Entri dengan nomor AWS akun yang berbeda di DBClusterArn bidang mewakili cluster yang dapat Anda kloning dan yang dimiliki oleh akun lain. AWS Entri tersebut memiliki beberapa bidang selain DBClusterArn. Saat membuat klaster yang diklon, tentukan nilai StorageEncrypted, Engine, dan EngineVersion yang sama seperti dalam klaster asli.

    Contoh berikut menunjukkan nilai yang dihasilkan yang menunjukkan klaster yang dikloning yang sebenarnya dan potensial. 

    {
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0"
      }
  ]
}