Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menggunakan aliran Neptunus replikasi lintas wilayah untuk pemulihan bencana
Neptune menyediakan dua cara untuk menerapkan kemampuan failover lintas-wilayah:
+ Salinan dan pemulihan snapshot lintas-wilayah
+ Menggunakan pengaliran Neptune untuk mereplikasi data antara dua klaster di dua wilayah yang berbeda.
Salinan dan pemulihan snapshot lintas-wilayah memiliki overhead operasional terendah untuk memulihkan klaster Neptune di wilayah yang berbeda. Namun, menyalin snapshot antar daerah memerlukan waktu transfer data yang signifikan, karena snapshot adalah cadangan penuh dari klaster Neptune. Hasilnya, salinan dan pemulihan snapshot lintas-wilayah dapat digunakan sebagai skenario yang hanya memerlukan Recovery Point Objective (RPO) jam dan waktu pemulihan tujuan (RTO) jam.
Recovery Point Objective (RPO) diukur dengan waktu di antara backup. Ini mendefinisikan berapa banyak data yang mungkin hilang antara waktu cadangan terakhir dibuat dan waktu di mana database dipulihkan.
Recovery Point Objective (RTO) diukur dengan waktu yang diperlukan untuk melaksanakan operasi pemulihan. Ini adalah waktu yang dibutuhkan klaster DB melakukan fail over ke database yang dipulihkan setelah terjadi kegagalan.
Pengaliran Neptune menyediakan cara untuk menjaga backup klaster Neptune sinkron dengan klaster produksi utama setiap saat. Jika terjadi kegagalan, database Anda kemudian gagal ke klaster backup. Hal ini mengurangi RPO dan RTO hingga ukuran menit, karena data terus-menerus disalin ke klaster backup, yang segera tersedia sebagai target failover setiap saat.
Kelemahan menggunakan pengaliran Neptune dengan cara ini adalah bahwa kedua overhead operasional yang diperlukan untuk mempertahankan komponen replikasi, dan biaya memiliki kedua Neptune DB klaster online sepanjang waktu, menjadi signifikan.
# Menyiapkan Neptune-to-Neptune replikasi
Klaster DB produksi utama Anda berada di VPC di wilayah sumber tertentu. Ada tiga hal utama yang Anda butuhkan untuk meniru atau menyamai di wilayah pemulihan yang berbeda untuk tujuan pemulihan bencana:
+ Data yang disimpan dalam klaster.
+ Konfigurasi klaster utama. Ini akan mencakup apakah menggunakan otentikasi IAM, apakah itu dienkripsi, parameter klaster DB-nya, parameter instans-nya, ukuran instans, dan sebagainya).
+ Topologi jaringan yang digunakan, termasuk di dalamnya target VPC, grup keamanan, dan sebagainya.
Anda dapat menggunakan APIs manajemen Neptunus seperti berikut ini untuk mengumpulkan informasi tersebut:
+ [`DescribeDBClusters`](api-clusters.md#DescribeDBClusters)
+ [`DescribeDBInstances`](api-instances.md#DescribeDBInstances)
+ [`DescribeDBClusterParameters`](api-parameters.md#DescribeDBClusterParameters)
+ [`DescribeDBParameters`](api-parameters.md#DescribeDBParameters)
+ [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
Dengan informasi yang Anda kumpulkan, Anda dapat menggunakan prosedur berikut ini untuk mengatur claster backup di wilayah yang berbeda, saat klaster produksi Anda gagal ke peristiwa kegagalan.
## Aktifkan aliran Neptunus
Anda dapat menggunakan [Memodifikasi DBCluster ParameterGroup](api-parameters.md#ModifyDBClusterParameterGroup) untuk mengatur parameter `neptune_streams` ke 1. Kemudian, reboot semua instans di klaster DB sehingga perubahan berlaku.
Adalah ide yang baik untuk melakukan setidaknya satu operasi tambahan atau operasi pembaruan pada klaster DB sumber setelah pengaliran Neptune telah diaktifkan. Ini mengisi pengaliran perubahan dengan titik data yang dapat direferensikan kemudian, ketika mesinkronkan ulang klaster produksi dengan cluster backup.
## Buat VPC baru di wilayah tempat Anda ingin menyiapkan klaster cadangan
Sebelum membuat klaster DB Neptune baru di wilayah yang berbeda dari klaster utama Anda, Anda perlu membangun VPC baru di wilayah target untuk menjadi tuan rumah cluster. Konektivitas antara cluster primer dan cadangan dibuat melalui peering VPC, yang menggunakan lalu lintas lintas subnet pribadi secara berbeda. VPCs Namun, untuk membuat VPC mengintip di antara dua VPCs, mereka tidak boleh memiliki blok CIDR atau ruang alamat IP yang tumpang tindih. Hal ini bahwa Anda tidak bisa hanya menggunakan VPC default di kedua wilayah, karena blok CIDR untuk VPC default selalu sama (`172.31.0.0/16`).
Anda dapat menggunakan VPC yang ada di wilayah target selama memenuhi kondisi berikut:
+ Ini tidak memiliki blok CIDR yang tumpang tindih dengan blok CIDR VPC tempat klaster utama Anda berada.
+ Hal ini belum dipasangkan dengan VPC lain yang memiliki blok CIDR yang sama seperti VPC tempat klaster utama Anda berada.
Jika tidak ada VPC yang cocok tersedia di wilayah target, buatlah satu menggunakan Amazon EC2 [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpc.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpc.html) API.
## Buat snapshot dari cluster utama Anda dan kembalikan ke wilayah cadangan target
Sekarang Anda membuat klaster Neptune baru di VPC yang sesuai di wilayah target cadangan yang merupakan salinan klaster produksi Anda:
**Membuat salinan klaster produksi Anda di wilayah cadangan**
1. Di wilayah backup target Anda, buat ulang parameter dan grup parameter yang digunakan oleh klaster DB produksi Anda. Anda dapat melakukannya menggunakan [`CreateDBClusterParameterGroup`](api-parameters.md#CreateDBClusterParameterGroup), [`CreateDBParameterGroup`](api-parameters.md#CreateDBParameterGroup), [`ModifyDBClusterParameterGroup`](api-parameters.md#ModifyDBClusterParameterGroup), dan [`ModifyDBParameterGroup`](api-parameters.md#ModifyDBParameterGroup).
Perhatikan bahwa [`CopyDBClusterParameterGroup`](api-parameters.md#CopyDBClusterParameterGroup)dan saat ini [`CopyDBParameterGroup`](api-parameters.md#CopyDBParameterGroup) APIs tidak mendukung penyalinan lintas wilayah.
1. Gunakan [`CreateDBClusterSnapshot`](api-snapshots.md#CreateDBClusterSnapshot) untuk membuat snapshot dari klaster produksi Anda di VPC di wilayah produksi Anda.
1. Gunakan [`CopyDBClusterSnapshot`](api-snapshots.md#CopyDBClusterSnapshot) untuk menyalin snapshot ke VPC di wilayah cadangan target Anda.
1. Gunakan [`RestoreDBClusterFromSnapshot`](api-snapshots.md#RestoreDBClusterFromSnapshot) untuk membuat klaster DB baru di VPC di wilayah cadangan target Anda menggunakan snapshot salinan. Gunakan pengaturan konfigurasi dan parameter yang Anda salin dari klaster produksi utama Anda.
1. Klaster Neptune baru sekarang ada tetapi tidak mengandung instans apapun. Gunakan [`CreateDBInstance`](api-instances.md#CreateDBInstance)untuk membuat primary/writer instance baru yang memiliki jenis dan ukuran instance yang sama dengan instance penulis klaster produksi Anda. Tidak perlu membuat replika baca tambahan pada saat ini kecuali instance cadangan Anda akan digunakan untuk membaca layanan I/O di wilayah target sebelum failover.
## Buat peering VPC antara VPC klaster utama Anda dan VPC cluster cadangan baru Anda
Dengan menyiapkan peering VPC, Anda mengaktifkan VPC klaster utama untuk berkomunikasi dengan VPC klaster backup Anda seolah-olah mereka adalah jaringan pribadi tunggal. Untuk melakukannya, Anda harus melakukan langkah-langkah berikut:
1. Dari VPC klaster produksi Anda, panggil [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateVpcPeeringConnection.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateVpcPeeringConnection.html) API untuk membangun koneksi peering.
1. Dari VPC klaster backup target Anda, panggil API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/AcceptVpcPeeringConnection.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/AcceptVpcPeeringConnection.html) untuk menerima koneksi peering.
1. Dari VPC klaster produksi Anda, gunakan API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html) untuk menambahkan rute ke tabel rute VPC yang mengarahkan semua lalu lintas ke blok CIDR VPC target sehingga menggunakan daftar awalan peering VPC.
1. Demikian pula, dari kluster cadangan target Anda VPC, gunakan API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html) untuk menambahkan rute ke tabel rute VPC yang merutekan lalu lintas ke VPC klaster utama.
## Siapkan infrastruktur replikasi aliran Neptunus
Sekarang kedua cluster dikerahkan dan komunikasi jaringan antara kedua wilayah telah dibuat, gunakan template [Neptunus-ke-Neptunus CloudFormation untuk menyebarkan fungsi Lambda konsumen aliran Neptunus](streams-consumer-setup.md) dengan infrastruktur tambahan yang mendukung replikasi data. Lakukan ini di VPC kluster produksi utama Anda.
Parameter yang perlu Anda sediakan untuk CloudFormation tumpukan ini adalah:
+ **`NeptuneStreamEndpoint`** – Titik akhir pengaliran untuk klaster utama, dalam format URL. Sebagai contoh: `https://(cluster name):8182/pg/stream`.
+ **`QueryEngine`**Ini harus salah satu`gremlin`,`sparql`, atau`openCypher`.
+ **`RouteTableIds`** – Memungkinkan Anda menambahkan rute untuk VPC Endpoint DynamoDB dan VPC Endpoint pemantauan.
Dua parameter tambahan, yaitu `CreateMonitoringEndpoint` dan `CreateDynamoDBEndpoint`, juga harus diatur ke benar jika mereka tidak sudah ada pada VPC klaster utama. Jika mereka sudah ada, pastikan mereka disetel ke false atau CloudFormation kreasi akan gagal.
+ **`SecurityGroupIds`** – Menentukan grup keamanan yang digunakan oleh konsumen Lambda untuk berkomunikasi dengan titik akhir pengaliran Neptune klaster utama.
Di kluster backup target, lampirkan grup keamanan yang memungkinkan lalu lintas yang berasal dari grup keamanan ini.
+ **`SubnetIds`** – Daftar ID subnet di VPC klaster utama yang dapat digunakan oleh konsumen Lambda untuk berkomunikasi dengan klaster utama.
+ **`TargetNeptuneClusterEndpoint`**— Titik akhir cluster (hanya nama host) dari cluster cadangan target.
+ **`TargetAWSRegion`**— AWS Wilayah cluster cadangan target, seperti`us-east-1`). Anda harus memberikan parameter ini hanya ketika AWS wilayah cluster cadangan target berbeda dari wilayah cluster sumber Neptunus, seperti dalam kasus replikasi lintas wilayah. Jika wilayah sumber dan target sama, parameter ini opsional.
Perhatikan bahwa jika `TargetAWSRegion` nilainya bukan [AWS wilayah valid yang didukung Neptunus](limits.md#limits-regions), prosesnya gagal.
+ **`VPC`** – ID VPC klaster utama.
Semua parameter lainnya dapat dibiarkan dengan nilai defaultnya.
Setelah CloudFormation template telah digunakan, Neptunus akan mulai mereplikasi setiap perubahan dari cluster utama ke cluster cadangan. Anda dapat memantau replikasi ini di CloudWatch log yang dihasilkan oleh fungsi konsumen Lambda.
# Pertimbangan lainnya
+ Jika Anda perlu menggunakan otentikasi IAM antara cluster primer dan cadangan, Anda juga dapat mengaturnya saat Anda memanggil template. CloudFormation
+ Jika enkripsi saat istirahat diaktifkan di klaster utama Anda, pertimbangkan cara mengelola kunci KMS yang terkait saat menyalin snapshot di wilayah target dan mengaitkan kunci KMS baru di wilayah target.
+ Praktik terbaik adalah menggunakan DNS CNAMEs di depan titik akhir Neptunus yang digunakan dalam aplikasi Anda. Kemudian, jika Anda perlu melakukan failover secara manual ke cluster cadangan target, ini CNAMEs dapat diubah untuk menunjuk ke titik akhir and/or instance cluster target.