Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Bekerja dengan instance AWS DMS replikasi
Saat Anda membuat instance AWS DMS replikasi, AWS DMS buat instans Amazon EC2 di virtual private cloud (VPC) berdasarkan layanan Amazon VPC. Anda menggunakan instans replikasi ini untuk melakukan migrasi basis data Anda. Dengan menggunakan instans replikasi, Anda bisa mendapatkan ketersediaan tinggi dan dukungan failover dengan deployment Multi-AZ saat Anda memilih opsi **Multi-AZ**.
Dalam penerapan Multi-AZ, AWS DMS secara otomatis menyediakan dan memelihara replika siaga sinkron dari instance replikasi di Availability Zone yang berbeda. Instans replikasi primer direplikasi secara sinkron di seluruh Availability Zone ke replika siaga. Pendekatan ini memberikan redundansi data, menghilangkan I/O pembekuan, dan meminimalkan lonjakan latensi.
![\[AWS Contoh replikasi Layanan Migrasi Database\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-conceptual2.png)
AWS DMS menggunakan contoh replikasi untuk terhubung ke penyimpanan data sumber Anda, membaca data sumber, dan memformat data untuk konsumsi oleh penyimpanan data target. Instans replikasi juga memuat data ke penyimpanan data target. Sebagian besar pemrosesan ini terjadi di memori. Namun, transaksi Large mungkin memerlukan beberapa buffering pada disk. Transaksi ter-cache dan berkas log juga ditulis ke disk.
Anda dapat membuat instance AWS DMS replikasi di AWS Wilayah berikut.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS mendukung AWS Wilayah khusus yang disebut AWS GovCloud (US) yang dirancang untuk memungkinkan lembaga pemerintah AS dan pelanggan memindahkan beban kerja sensitif ke cloud. AWS GovCloud (US) menangani persyaratan peraturan dan kepatuhan khusus pemerintah AS. Untuk informasi lebih lanjut tentang AWS GovCloud (US), lihat [Apa itu AWS GovCloud (AS)?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
Di bawah ini, Anda bisa mendapatkan detail lebih lanjut tentang instans replikasi.
**Topics**
+ [Memilih instans replikasi AWS DMS yang tepat untuk migrasi Anda](CHAP_ReplicationInstance.Types.md)
+ [Memilih ukuran terbaik untuk contoh replikasi](CHAP_BestPractices.SizingReplicationInstance.md)
+ [Bekerja dengan versi mesin replikasi](CHAP_ReplicationInstance.EngineVersions.md)
+ [Instans replikasi publik dan privat](CHAP_ReplicationInstance.PublicPrivate.md)
+ [Alamat IP dan jenis jaringan](CHAP_ReplicationInstance.IPAddressing.md)
+ [Menyiapkan jaringan untuk instans replikasi](CHAP_ReplicationInstance.VPC.md)
+ [Mengatur kunci enkripsi untuk instans replikasi](CHAP_ReplicationInstance.EncryptionKey.md)
+ [Membuat instans replikasi](CHAP_ReplicationInstance.Creating.md)
+ [Mengubah instans replikasi](CHAP_ReplicationInstance.Modifying.md)
+ [Mem-boot ulang instans replikasi](CHAP_ReplicationInstance.Rebooting.md)
+ [Menghapus instans replikasi](CHAP_ReplicationInstance.Deleting.md)
+ [Bekerja dengan jendela AWS DMS pemeliharaan](CHAP_ReplicationInstance.MaintenanceWindow.md)
# Memilih instans replikasi AWS DMS yang tepat untuk migrasi Anda
AWS DMS membuat instance replikasi pada instans Amazon EC2. AWS DMS saat ini mendukung kelas instans Amazon EC2 T3, C5, C6i, R5, dan R6i untuk instance replikasi:
+ Instans T3 adalah tipe instans tujuan umum yang dapat dilonjakkan generasi berikutnya. Tipe ini menyediakan performa CPU tingkat baseline dengan kemampuan untuk meningkatkan penggunaan CPU kapan saja selama yang diperlukan. Instans T3 menawarkan keseimbangan komputasi, memori, dan sumber daya jaringan serta dirancang untuk aplikasi dengan penggunaan CPU moderat yang mengalami lonjakan sementara pada saat digunakan. Instans T3 mengumpulkan kredit CPU ketika beban kerja beroperasi di bawah ambang batas baseline. Setiap kredit CPU yang diperoleh memberikan kesempatan pada instans T3 untuk melonjak dengan performa satu core CPU selama satu menit bila diperlukan.
Instans T3 dapat melonjak kapan saja selama yang diperlukan dalam mode `unlimited`. Untuk informasi lebih lanjut tentang mode `unlimited`, lihat [Bekerja dengan mode tak terbatas untuk instans performa yang dapat dilonjakkan](#CHAP_ReplicationInstance.Types.UnlimitedMode).
+ Instans C5 adalah tipe instans generasi berikutnya yang digunakan untuk memberikan performa tinggi yang hemat biaya dengan rasio harga per komputasi yang rendah untuk menjalankan beban kerja intensif komputasi lanjutan. Beban kerja tersebut termasuk server web performa tinggi, komputasi performa tinggi (HPC), pemrosesan batch, penayangan iklan, game multipemain yang dapat diskalakan, dan pengkodean video. Instans C5 beban kerja lainnya cocok untuk mencakup pemodelan ilmiah, analitik terdistribusi, dan inferensi mesin dan deep learning. Instans C5 tersedia dengan pilihan prosesor dari Intel dan AMD.
+ Instans C6i menawarkan kinerja harga komputasi hingga 15% lebih baik dibandingkan instans Gen5 yang sebanding untuk berbagai macam beban kerja, dan enkripsi memori yang selalu aktif. Instans C6i sangat cocok untuk beban kerja intensif komputasi seperti pemrosesan batch, analitik terdistribusi, komputasi kinerja tinggi (HPC), penayangan iklan, game multipemain yang sangat skalabel, dan pengkodean video.
+ Instans R5 adalah generasi berikutnya dari tipe instans memori yang dioptimalkan untuk memori untuk Amazon EC2. Instans R5 sangat sesuai untuk aplikasi intensif memori seperti basis data performa tinggi, cache dalam memori skala web terdistribusi, basis data dalam memori berukuran sedang, analitik big data waktu nyata, dan aplikasi korporasi lainnya. Migrasi yang sedang berlangsung atau replikasi sistem transaksi throughput tinggi yang digunakan juga AWS DMS dapat mengkonsumsi CPU dan memori dalam jumlah besar.
+ Instans R6i menawarkan kinerja harga komputasi hingga 15% lebih baik dibandingkan instans Gen5 yang sebanding untuk berbagai macam beban kerja, dan enkripsi memori yang selalu aktif. Instans R6i adalah SAP Certified dan ideal untuk beban kerja seperti database SQL dan NoSQL, cache dalam memori skala web terdistribusi seperti Memcached dan Redis OSS, database dalam memori seperti SAP HANA, dan analisis data besar real time seperti cluster Hadoop dan Spark.
+ Instans C7i menawarkan kinerja komputasi yang lebih baik dibandingkan instance generasi sebelumnya yang sebanding. Untuk AWS DMS beban kerja, instans C7i unggul dalam mempercepat proses transformasi data, menangani konversi skema berat komputasi, dan mempertahankan throughput yang konsisten selama tugas migrasi volume tinggi. Instans ini memberikan keseimbangan ideal kinerja komputasi yang membutuhkan kinerja CPU yang berkelanjutan.
+ Instans R7i menawarkan kinerja komputasi yang lebih baik dibandingkan instans generasi sebelumnya yang sebanding, dikombinasikan dengan kapasitas memori yang tinggi untuk beban kerja intensif memori. Untuk AWS DMS beban kerja, instans R7i sangat cocok untuk tugas-tugas yang melibatkan database besar yang memproses volume tinggi transaksi database bersamaan, memungkinkan penanganan yang efisien dari skenario replikasi intensif memori dan proses validasi data kompleks yang memerlukan buffer memori yang substansif.
Setiap instans replikasi memiliki konfigurasi memori dan vCPU tertentu. Tabel berikut menunjukkan konfigurasi untuk setiap tipe instans replikasi. Untuk informasi harga, lihat [AWS Database Migration Service halaman harga layanan](https://aws.amazon.com/dms/pricing/).
**Jenis Instans Replikasi Tujuan Umum**
| Tipe | vCPU | Memori (GiB) |
| --- | --- | --- |
| dms.t3.micro | 2 | 1 |
| dms.t3.small | 2 | 2 |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**Menghitung Jenis Instans Replikasi yang Dioptimalkan**
| Tipe | vCPU | Memori (GiB) |
| --- | --- | --- |
| dms.c5.large | 2 | 4 |
| dms.c5.xlarge | 4 | 8 |
| dms.c5.2xlarge | 8 | 16 |
| dms.c5.4xlarge | 16 | 32 |
| dms.c5.9xlarge | 36 | 72 |
| dms.c5.12xlarge | 48 | 96 |
| dms.c5.18xlarge | 72 | 144 |
| dms.c5.24xlarge | 96 | 192 |
| dms.c6i.large | 2 | 4 |
| dms.c6i.xlarge | 4 | 8 |
| dms.c6i.2xlarge | 8 | 16 |
| dms.c6i.4xlarge | 16 | 32 |
| dms.c6i.8xlarge | 32 | 64 |
| dms.c6i.12xlarge | 48 | 96 |
| dms.c6i.16xlarge | 64 | 128 |
| dms.c6i.24xlarge | 96 | 192 |
| dms.c6i.32xlarge | 128 | 256 |
| dms.c7i.large | 2 | 4 |
| dms.c7i.xlarge | 4 | 8 |
| dms.x7i.2xlarge | 8 | 16 |
| dms.x7i.4xlarge | 16 | 32 |
| dms.x7i.8xlarge | 32 | 64 |
| dms.x7i.12xlarge | 48 | 96 |
| dms.x7i.16xlarge | 64 | 128 |
| dms.x7i.24xlarge | 96 | 192 |
| dms.x7i.48xlarge | 192 | 384 |
**Jenis Instans Replikasi yang Dioptimalkan Memori**
| Tipe | vCPU | Memori (GiB) |
| --- | --- | --- |
| dms.r5.large | 2 | 16 |
| dms.r5.xlarge | 4 | 32 |
| dms.r5.2xlarge | 8 | 64 |
| dms.r5.4xlarge | 16 | 128 |
| dms.r5.8xlarge | 32 | 256 |
| dms.r5.12xlarge | 48 | 384 |
| dms.r5.16xlarge | 64 | 512 |
| dms.r5.24xlarge | 96 | 768 |
| dms.r6i.large | 2 | 16 |
| dms.r6i.xlarge | 4 | 32 |
| dms.r6i.2xlarge | 8 | 64 |
| dms.r6i.4xlarge | 16 | 128 |
| dms.r6i.8xlarge | 32 | 256 |
| dms.r6i.12xlarge | 48 | 384 |
| dms.r6i.16xlarge | 64 | 512 |
| dms.r6i.24xlarge | 96 | 768 |
| dms.r6i.32xlarge | 128 | 1024 |
| dms.r7i.large | 2 | 16 |
| dms.r7i.xlarge | 4 | 32 |
| dms.r7i.2xlarge | 8 | 64 |
| dms.r7i.4xlarge | 16 | 128 |
| dms.r7i.8xlarge | 32 | 256 |
| dms.r7i.12xlarge | 48 | 384 |
| dms.r7i.16xlarge | 64 | 512 |
| dms.r7i.24xlarge | 96 | 768 |
| dms.r7i.48xlarge | 192 | 1536 |
Tabel di atas mencantumkan semua jenis contoh AWS DMS replikasi, tetapi jenis yang tersedia di wilayah Anda mungkin berbeda. Untuk melihat jenis instance replikasi yang tersedia di wilayah Anda, Anda dapat menjalankan [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)perintah berikut:
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [Menentukan kelas instans yang digunakan](#CHAP_ReplicationInstance.Types.Deciding)
+ [Bekerja dengan mode tak terbatas untuk instans performa yang dapat dilonjakkan](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## Menentukan kelas instans yang digunakan
Untuk membantu menentukan kelas instance replikasi mana yang paling cocok untuk Anda, mari kita lihat proses change data capture (CDC) yang AWS DMS digunakan.
Mari kita asumsikan bahwa Anda sedang menjalankan beban penuh ditambah dengan tugas CDC (beban massal ditambah dengan replikasi yang sedang berlangsung). Dalam hal ini, tugas memiliki SQLite repositori sendiri untuk menyimpan metadata dan informasi lainnya. Sebelum AWS DMS memulai beban penuh, langkah-langkah ini terjadi:
+ AWS DMS mulai menangkap perubahan untuk tabel yang dimigrasikan dari log transaksi mesin sumber (kami menyebutnya perubahan *cache*). Setelah beban penuh dilakukan, perubahan ter-cache tersebut dikumpulkan dan diterapkan pada target. Tergantung pada volume perubahan ter-cache, perubahan tersebut dapat langsung diterapkan dari memori, di mana mereka pertama kali dikumpulkan, hingga ambang batas yang ditetapkan. Atau mereka dapat diterapkan dari disk, di mana perubahan ditulis ketika perubahan tersebut tidak dapat disimpan di memori.
+ Setelah perubahan cache diterapkan, secara default AWS DMS memulai proses penerapan transaksional pada instance target.
Selama fase perubahan cache yang diterapkan dan fase replikasi yang sedang berlangsung, AWS DMS menggunakan dua buffer aliran, masing-masing untuk data masuk dan keluar. AWS DMS juga menggunakan komponen penting yang disebut *penyortir,* yang merupakan buffer memori lain. Berikut ini adalah dua kegunaan penting dari komponen penyortir (yang memiliki kegunaan lain):
+ Penyortir melacak semua transaksi dan memastikan bahwa penyortir hanya meneruskan transaksi yang relevan untuk buffer keluar.
+ Penyortir memastikan bahwa transaksi diteruskan dalam urutan perlakuan yang sama seperti pada sumber.
Seperti yang Anda lihat, kami memiliki tiga buffer memori penting dalam arsitektur ini untuk CDC di AWS DMS. Jika salah satu buffer tersebut mengalami tekanan memori, migrasi dapat memiliki masalah performa yang berpotensi menyebabkan kegagalan.
Ketika Anda memasukkan beban kerja berat dengan jumlah transaksi per detik (TPS) yang tinggi ke dalam arsitektur ini, Anda dapat menemukan memori tambahan yang disediakan oleh instans R5 dan R6i berguna. Anda dapat menggunakan instans R5 dan R6i untuk menyimpan sejumlah besar transaksi dalam memori dan mencegah masalah tekanan memori selama replikasi yang sedang berlangsung.
## Bekerja dengan mode tak terbatas untuk instans performa yang dapat dilonjakkan
Instans performa yang dapat dilonjakkan yang dikonfigurasi sebagai `unlimited`, seperti instans T3, dapat mempertahankan pemakaian CPU yang tinggi untuk jangka waktu apa pun kapan pun diperlukan. Harga instans per jam dapat secara otomatis mencakup semua lonjakan penggunaan CPU. Hal tersebut terjadi jika penggunaan CPU rata-rata dari instans berada pada atau di bawah baseline selama periode 24 jam bergulir atau masa pakai instans, mana saja yang lebih pendek.
Untuk sebagian besar beban kerja tujuan umum, instans yang dikonfigurasi sebagai `unlimited` memberikan performa yang cukup tanpa biaya tambahan. Jika instans berjalan pada pemakaian CPU yang lebih tinggi untuk waktu yang lama, instans dapat melakukannya dengan tarif tambahan tetap per jam vCPU. Untuk informasi tentang harga instans T3, lihat "Kredit CPU T3" di [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
*Untuk informasi selengkapnya tentang `unlimited` mode untuk instans T3, lihat [Mode tak terbatas untuk instans performa burstable di Panduan Pengguna](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) Amazon EC2.*
**penting**
Jika Anda menggunakan instans `dms.t3.micro` di bawah penawaran [Tingkat Gratis AWS](https://aws.amazon.com/free/) dan menggunakannya dalam mode `unlimited`, biaya mungkin berlaku. Secara khusus, biaya mungkin berlaku jika penggunaan rata-rata selama periode 24 jam bergulir melebihi pemanfaatan dasar instans. Untuk informasi [selengkapnya, lihat Pemanfaatan dasar di Panduan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) Pengguna *Amazon* EC2.
Instans T3 diluncurkan sebagai `unlimited` secara default. Jika penggunaan CPU rata-rata selama periode 24 jam melebihi standar, Anda dikenai biaya untuk kelebihan kredit. Dalam beberapa kasus, Anda mungkin meluncurkan Instans Spot T3 sebagai `unlimited` dan berencana untuk segera menggunakannya dan untuk durasi yang singkat. Jika Anda melakukannya tanpa waktu diam untuk memperoleh kredit CPU, Anda dikenakan biaya untuk kelebihan kredit. Kami menyarankan Anda untuk meluncurkan Instans Spot T3 dalam mode standar untuk menghindari pembayaran biaya yang lebih tinggi. *Untuk informasi selengkapnya, lihat [Kredit surplus dapat dikenakan biaya](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits), Instans [Spot T3, dan mode Standar untuk instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances) [performa burstable di](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) Panduan Pengguna Amazon EC2.*
# Memilih ukuran terbaik untuk contoh replikasi
Memilih instans replikasi yang sesuai tergantung pada beberapa faktor kasus penggunaan Anda. Untuk membantu memahami bagaimana sumber daya instans replikasi digunakan, lihat diskusi berikut. Ini mencakup skenario umum beban penuh \$1 tugas CDC.
Selama tugas beban penuh, AWS DMS memuat tabel satu per satu. Secara default, delapan tabel dimuat sekaligus. AWS DMS menangkap perubahan yang sedang berlangsung pada sumber selama tugas pemuatan penuh sehingga perubahan dapat diterapkan nanti pada titik akhir target. Perubahan disimpan dalam memori; jika memori yang tersedia habis, perubahan disimpan ke disk. Ketika tugas beban penuh selesai untuk tabel, AWS DMS segera terapkan perubahan cache ke tabel target.
Setelah semua perubahan ter-cache yang tertunda untuk sebuah tabel telah diterapkan, titik akhir target berada dalam keadaan konsisten secara transaksi. Pada titik ini, target sinkron dengan titik akhir sumber sehubungan dengan perubahan cache terakhir. AWS DMS kemudian mulai replikasi berkelanjutan antara sumber dan target. Untuk melakukannya, AWS DMS mengambil operasi perubahan dari log transaksi sumber dan menerapkannya ke target dengan cara yang konsisten secara transaksional. (Proses ini mengasumsikan penerapan yang dioptimalkan batch tidak dipilih). AWS DMS mengalirkan perubahan yang sedang berlangsung melalui memori pada instance replikasi, jika memungkinkan. Jika tidak, AWS DMS tulis perubahan pada disk pada instance replikasi hingga dapat diterapkan pada target.
Anda dapat mengontrol bagaimana instans replikasi menangani pemrosesan perubahan, dan bagaimana memori digunakan dalam proses tersebut. Untuk informasi lebih lanjut tentang cara mengatur pemrosesan perubahan, lihat [Mengubah pengaturan penyetelan pemrosesan](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
## Faktor yang perlu dipertimbangkan
Memori dan ruang disk adalah faktor kunci dalam memilih contoh replikasi yang sesuai untuk kasus penggunaan Anda. Berikut ini, Anda dapat menemukan diskusi tentang karakteristik kasus penggunaan untuk menganalisis untuk memilih contoh replikasi.
+ Database dan ukuran tabel
Volume data membantu menentukan konfigurasi tugas untuk mengoptimalkan kinerja beban penuh. Misalnya, untuk dua skema 1 TB, Anda dapat mempartisi tabel menjadi empat tugas 500 GB dan menjalankannya secara paralel. Paralelisme yang mungkin tergantung pada sumber daya CPU yang tersedia dalam contoh replikasi. Itu sebabnya ide yang baik memahami ukuran database dan tabel Anda untuk mengoptimalkan kinerja beban penuh. Ini membantu menentukan jumlah tugas yang mungkin Anda miliki.
+ Benda besar
Tipe data yang ada dalam lingkup migrasi Anda dapat memengaruhi kinerja. Khususnya, objek besar (LOBs) berdampak pada kinerja dan konsumsi memori. Untuk memigrasikan nilai LOB, AWS DMS lakukan proses dua langkah. Pertama, AWS DMS masukkan baris ke target tanpa nilai LOB. Kedua, AWS DMS memperbarui baris dengan nilai LOB. Ini berdampak pada memori, jadi penting untuk mengidentifikasi kolom LOB di sumber dan menganalisis ukurannya.
+ Frekuensi beban dan ukuran transaksi
Frekuensi beban dan transaksi per detik (TPS) mempengaruhi penggunaan memori. Tingginya jumlah aktivitas TPS atau data manipulation language (DHTML) menyebabkan penggunaan memori yang tinggi. Ini terjadi karena DMS menyimpan perubahan sampai diterapkan ke target. Selama CDC, ini menyebabkan pertukaran (menulis ke disk fisik karena luapan memori), yang menyebabkan latensi.
+ Tombol tabel dan integritas referensial
Informasi tentang kunci tabel menentukan mode CDC (penerapan batch atau berlaku transaksional) yang Anda gunakan untuk memigrasikan data. Secara umum, penerapan transaksional lebih lambat daripada penerapan batch. Untuk transaksi yang berjalan lama, mungkin ada banyak perubahan untuk bermigrasi. Saat Anda menggunakan aplikasi transaksional, AWS DMS mungkin memerlukan lebih banyak memori untuk menyimpan perubahan dibandingkan dengan penerapan batch. Jika Anda memigrasikan tabel tanpa kunci utama, penerapan batch akan gagal dan tugas DMS pindah ke mode penerapan transaksional. Ketika integritas referensial aktif antara tabel selama CDC, AWS DMS menggunakan penerapan transaksional secara default. Untuk informasi lebih lanjut tentang penerapan batch dibandingkan dengan penerapan transaksional, [lihat Bagaimana cara menggunakan fitur penerapan batch DMS untuk meningkatkan kinerja replikasi CDC?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/) .
Gunakan metrik ini untuk menentukan apakah Anda memerlukan instance replikasi untuk dioptimalkan komputasi atau memori dioptimalkan.
## Masalah umum
Anda mungkin menghadapi masalah umum berikut yang menyebabkan pertentangan sumber daya pada instance replikasi selama migrasi. Untuk informasi tentang metrik instance replikasi, lihat. [Metrik instans replikasi](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch)
+ Jika memori dalam contoh replikasi menjadi tidak mencukupi, ini menghasilkan penulisan data ke disk. Membaca dari disk dapat menyebabkan latensi, yang dapat Anda hindari dengan mengukur instance replikasi dengan memori yang cukup.
+ Ukuran disk yang ditetapkan untuk instance replikasi bisa lebih kecil dari yang dibutuhkan. Ukuran disk digunakan ketika data dalam memori tumpah; itu juga digunakan untuk menyimpan log tugas. IOPS maksimum juga tergantung padanya.
+ Menjalankan beberapa tugas atau tugas dengan paralelisme tinggi memengaruhi konsumsi CPU dari instance replikasi. Ini memperlambat pemrosesan tugas dan menghasilkan latensi.
## Praktik terbaik
Pertimbangkan dua praktik terbaik yang paling umum ini saat mengukur contoh replikasi. Untuk informasi selengkapnya, lihat [Praktik terbaik untuk AWS Database Migration Service](CHAP_BestPractices.md).
1. Ukur beban kerja Anda dan pahami apakah itu padat komputer atau intensif memori. Berdasarkan ini, Anda dapat menentukan kelas dan ukuran instance replikasi:
+ AWS DMS proses LOBs dalam memori. Operasi ini membutuhkan cukup banyak memori.
+ Jumlah tugas dan jumlah thread memengaruhi konsumsi CPU. Hindari menggunakan lebih dari delapan `MaxFullLoadSubTasks` selama operasi beban penuh.
1. Tingkatkan ruang disk yang ditetapkan ke instance replikasi saat Anda memiliki beban kerja yang tinggi selama beban penuh. Melakukan hal ini memungkinkan instance replikasi menggunakan IOPS maksimum yang ditetapkan untuk itu.
Pedoman sebelumnya tidak mencakup semua skenario yang mungkin. Penting untuk mempertimbangkan secara spesifik kasus penggunaan khusus Anda saat Anda menentukan ukuran instance replikasi Anda.
Tes sebelumnya menunjukkan CPU dan memori bervariasi dengan beban kerja yang berbeda. Khususnya, LOBs mempengaruhi memori, dan jumlah tugas atau paralelisme mempengaruhi CPU. Setelah migrasi Anda berjalan, pantau CPU, memori yang dapat dibebaskan, penyimpanan gratis, dan IOPS dari instance replikasi Anda. Berdasarkan data yang Anda kumpulkan, Anda dapat menambah atau mengurangi ukuran instans replikasi Anda sesuai kebutuhan.
# Bekerja dengan versi mesin replikasi
*Mesin replikasi* adalah AWS DMS perangkat lunak inti yang berjalan pada instance replikasi Anda dan melakukan tugas migrasi yang Anda tentukan. AWS secara berkala merilis versi baru dari perangkat lunak mesin AWS DMS replikasi, dengan fitur baru dan peningkatan kinerja. Setiap versi perangkat lunak mesin replikasi memiliki nomor versi sendiri, untuk membedakannya dari versi lain.
Saat Anda meluncurkan instance replikasi baru, ia menjalankan versi AWS DMS mesin terbaru kecuali Anda menentukan sebaliknya. Untuk informasi selengkapnya, lihat [Bekerja dengan instance AWS DMS replikasi](CHAP_ReplicationInstance.md).
Jika Anda memiliki instance replikasi yang sedang berjalan, Anda dapat memutakhirkannya ke versi mesin yang lebih baru. (AWS DMS tidak mendukung penurunan versi mesin.) Untuk informasi lebih lanjut tentang versi mesin replikasi, lihat [AWS Catatan rilis DMS](CHAP_ReleaseNotes.md).
## Meningkatkan versi mesin menggunakan konsol
Anda dapat memutakhirkan instance AWS DMS replikasi menggunakan file. Konsol Manajemen AWS
**Untuk meningkatkan instans replikasi menggunakan konsol tersebut**
1. Buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Di panel navigasi, pilih **Instans replikasi**.
1. Pilih mesin replikasi Anda, dan kemudian pilih **Ubah**.
1. Untuk **versi Engine**, pilih nomor versi yang Anda inginkan, lalu pilih **Ubah**.
**catatan**
Sebaiknya hentikan semua tugas sebelum memutakhirkan Instance Replikasi. Jika Anda tidak menghentikan tugas, AWS DMS akan menghentikan tugas secara otomatis sebelum upgrade. Jika Anda menghentikan tugas secara manual, Anda harus memulai tugas secara manual setelah pemutakhiran selesai. Meningkatkan instans replikasi memerlukan waktu beberapa menit. Ketika instans siap, statusnya berubah menjadi **tersedia**.
## Memutakhirkan versi mesin menggunakan AWS CLI
Anda dapat memutakhirkan instance AWS DMS replikasi menggunakan AWS CLI, sebagai berikut.
**Untuk memutakhirkan instance replikasi menggunakan AWS CLI**
1. Tentukan Amazon Resource Name (ARN) instans replikasi Anda dengan menggunakan perintah berikut.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"
```
Dalam output, perhatikan ARN untuk instans replikasi yang ingin Anda tingkatkan, misalnya: `arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY`
1. Tentukan versi instans replikasi apa saja yang tersedia dengan menggunakan perintah berikut.
```
aws dms describe-orderable-replication-instances \
--query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"
```
Dalam output, perhatikan nomor versi mesin atau nomor yang tersedia untuk kelas instans replikasi Anda. Anda akan melihat informasi ini dalam output dari langkah 1.
1. Tingkatkan instans replikasi dengan menggunakan perintah berikut.
```
aws dms modify-replication-instance \
--replication-instance-arn arn \
--engine-version n.n.n
```
Ganti *arn* di sebelumnya dengan contoh replikasi ARN yang sebenarnya dari langkah sebelumnya.
Ganti *n.n.n * dengan nomor versi mesin yang Anda inginkan, misalnya: `3.4.5`
**catatan**
Meningkatkan instans replikasi memerlukan waktu beberapa menit. Anda dapat melihat status instans replikasi menggunakan perintah berikut.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"
```
Ketika instans replikasi siap, statusnya berubah ke **tersedia**.
# Instans replikasi publik dan privat
Anda dapat menentukan apakah instance replikasi memiliki alamat IP publik atau pribadi yang digunakan instance untuk terhubung ke basis data sumber dan target.
*Instans replikasi* privat memiliki alamat IP privat yang tidak dapat Anda akses di luar jaringan replikasi. Anda menggunakan instance pribadi ketika database sumber dan target berada di jaringan yang sama yang terhubung ke virtual private cloud (VPC) dari instance replikasi. Jaringan dapat dihubungkan ke VPC dengan menggunakan virtual private network (VPN) Direct Connect, atau VPC peering.
Koneksi *peering VPC* adalah koneksi jaringan antara dua. VPCs Hal ini memungkinkan routing menggunakan masing-masing alamat IP pribadi VPC seolah-olah mereka berada di jaringan yang sama. Untuk informasi lebih lanjut mengenai peering VPC, lihat [peering VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) dalam *Panduan Pengguna Amazon VPC*.
Sebuah *instance replikasi publik* dapat menggunakan grup keamanan VPC dari instance replikasi, dan alamat IP publik instance replikasi atau alamat IP publik gateway NAT. Koneksi tersebut membentuk jaringan yang Anda gunakan untuk migrasi data.
# Alamat IP dan jenis jaringan
AWS DMS selalu membuat instance replikasi Anda di Amazon Virtual Private Cloud (VPC). Saat membuat VPC, Anda dapat menentukan alamat IP yang akan digunakan: salah satu IPv4 atau IPv6, atau keduanya. Kemudian, ketika Anda membuat atau memodifikasi instance replikasi, Anda dapat menentukan penggunaan protokol IPv4 alamat atau protokol IPv6 alamat menggunakan mode *dual-stack*.
**IPv4 alamat**
Saat Anda membuat VPC, Anda dapat menentukan rentang IPv4 alamat untuk VPC dalam bentuk blok Classless Inter-Domain Routing (CIDR), seperti 10.0.0.0/16. Grup subnet mendefinisikan rentang alamat IP di blok CIDR ini. Alamat IP ini bisa bersifat privat atau publik.
Alamat IPv4 privat adalah alamat IP yang tidak dapat dijangkau dengan Internet. Anda dapat menggunakan alamat IPv4 pribadi untuk komunikasi antara instans replikasi dan sumber daya lainnya, seperti instans Amazon EC2, di VPC yang sama. Setiap contoh replikasi memiliki alamat IP pribadi untuk komunikasi di VPC.
Alamat IP publik adalah IPv4 alamat yang dapat dijangkau dari internet. Anda dapat menggunakan alamat publik untuk komunikasi antara contoh replikasi Anda dan sumber daya di internet. Anda mengontrol apakah instance replikasi Anda menerima alamat IP publik.
**Mode dan alamat tumpukan ganda IPv6 **
Bila Anda memiliki sumber daya yang harus berkomunikasi dengan instance replikasi Anda IPv6, gunakan mode *dual-stack*. Untuk menggunakan mode dual-stack, pastikan bahwa setiap subnet dalam grup subnet yang Anda kaitkan dengan instance replikasi memiliki blok IPv6 CIDR yang terkait dengannya. Anda dapat membuat grup subnet replikasi baru atau memodifikasi grup subnet replikasi yang ada untuk memenuhi persyaratan ini. Setiap IPv6 alamat unik secara global. Blok IPv6 CIDR untuk VPC Anda secara otomatis ditetapkan dari kumpulan IPv6 alamat Amazon. Anda tidak dapat memilih sendiri rentang tersebut.
DMS menonaktifkan akses Internet Gateway untuk IPv6 titik akhir instance replikasi mode dual-stack pribadi. DMS melakukan ini untuk memastikan bahwa IPv6 titik akhir Anda bersifat pribadi dan hanya dapat diakses dari dalam VPC Anda.
Anda dapat menggunakan AWS DMS Konsol untuk membuat atau memodifikasi instance replikasi, dan menentukan mode dual-stack di bagian Jenis **jaringan**. Gambar berikut menampilkan bagian **Jenis jaringan** di konsol.
![\[AWS Jenis Jaringan Layanan Migrasi Database\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-network-type.png)
**Referensi**
+ Untuk informasi tentang mode IPv4 dan IPv6 alamat, lihat [Pengalamatan IP](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) di Panduan Pengguna *Amazon VPC*.
+ Untuk informasi selengkapnya tentang membuat instance replikasi menggunakan mode dual-stack, lihat. [Membuat instans replikasi](CHAP_ReplicationInstance.Creating.md)
+ Untuk informasi mode tentang memodifikasi instance replikasi, lihat. [Mengubah instans replikasi](CHAP_ReplicationInstance.Modifying.md)
# Menyiapkan jaringan untuk instans replikasi
AWS DMS selalu membuat instance replikasi dalam VPC berbasis Amazon VPC. Anda menentukan VPC tempat instans replikasi Anda terletak. Anda dapat menggunakan VPC default untuk akun dan AWS Wilayah Anda, atau Anda dapat membuat VPC baru.
Pastikan bahwa antarmuka jaringan elastis yang dialokasikan untuk VPC instans replikasi Anda dikaitkan dengan grup keamanan. Pastikan juga bahwa aturan grup keamanan tersebut membiarkan semua lalu lintas pada semua port meninggalkan (keluar) VPC. Pendekatan ini memungkinkan komunikasi dari instance replikasi ke titik akhir basis data sumber dan target Anda, jika aturan ingress yang benar diaktifkan pada titik akhir. Kami merekomendasikan Anda untuk menggunakan pengaturan default untuk titik akhir, yang memungkinkan jalan keluar pada semua port ke semua alamat.
Titik akhir sumber dan target mengakses instans replikasi yang ada di dalam VPC baik dengan cara menghubungkan ke VPC atau dengan berada di dalam VPC. Titik akhir database harus menyertakan daftar kontrol akses jaringan (ACLs) dan aturan grup keamanan (jika berlaku) yang memungkinkan akses masuk dari instance replikasi. Cara Anda mengatur hal ini tergantung pada konfigurasi jaringan yang Anda gunakan. Anda dapat menggunakan grup keamanan VPC instans replikasi, alamat IP privat atau publik instans replikasi, atau alamat IP publik gateway NAT. Koneksi tersebut membentuk jaringan yang Anda gunakan untuk migrasi data.
**catatan**
Karena alamat IP dapat berubah sebagai akibat dari perubahan infrastruktur yang mendasarinya, kami sarankan Anda menggunakan rentang CIDR VPC, atau merutekan lalu lintas keluar instance replikasi Anda melalui IP Elastis terkait NAT GW. Untuk informasi selengkapnya tentang membuat VPC, termasuk blok CIDR, lihat [Bekerja dengan VPCs dan subnet](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) di Panduan Pengguna *Amazon Virtual Private Cloud*. Untuk informasi selengkapnya tentang alamat IP Elastis, lihat [Alamat IP Elastis](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html) di *Panduan Pengguna Amazon Elastic Compute Cloud*.
## Konfigurasi jaringan untuk migrasi basis data
Anda dapat menggunakan beberapa konfigurasi jaringan yang berbeda dengan AWS Database Migration Service. Berikut ini adalah konfigurasi umum untuk jaringan yang digunakan untuk migrasi basis data.
**Topics**
+ [Konfigurasi dengan semua komponen migrasi basis data dalam satu VPC](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [Konfigurasi dengan beberapa VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [Konfigurasi dengan bersama VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Konfigurasi untuk jaringan ke VPC menggunakan Direct Connect atau VPN](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [Konfigurasi untuk jaringan ke VPC menggunakan internet](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [Konfigurasi dengan instans RDS DB tidak dalam VPC ke instance DB di VPC menggunakan ClassicLink](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [Konfigurasi untuk jaringan yang terhubung ke AWS layanan](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [Konfigurasi untuk jaringan yang terhubung ke AWS layanan menggunakan titik akhir VPC](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [Konfigurasi untuk jaringan yang terhubung ke AWS layanan menggunakan internet](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
Jika praktis, kami menyarankan Anda membuat instance replikasi DMS di Wilayah yang sama dengan titik akhir target Anda, dan di VPC atau subnet yang sama dengan titik akhir target Anda.
### Konfigurasi dengan semua komponen migrasi basis data dalam satu VPC
Jaringan yang paling sederhana untuk migrasi basis data adalah jika titik akhir sumber, instans replikasi, dan titik akhir target berada di VPC yang sama. Konfigurasi ini termasuk baik jika titik akhir sumber dan target Anda berada di instans DB Amazon RDS atau instans Amazon EC2.
Ilustrasi berikut menunjukkan konfigurasi di mana basis data pada instans Amazon EC2 terhubung ke instans replikasi dan data dimigrasi ke instans DB Amazon RDS.
![\[AWS Database Migration Service Semua dalam satu contoh VPC\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
Grup keamanan VPC yang digunakan dalam konfigurasi ini harus mengizinkan ingress pada port basis data dari instans replikasi. Anda dapat melakukan ini dengan beberapa cara. Anda dapat memastikan bahwa grup keamanan yang digunakan oleh instans replikasi memiliki ingress ke titik akhir. Atau Anda dapat mengizinkan rentang VPC CIDR, NAT GW Elastic IP, atau alamat IP pribadi dari instance replikasi jika Anda menggunakannya. Tetapi kami tidak menyarankan Anda menggunakan alamat IP pribadi dari contoh replikasi, karena dapat merusak replikasi Anda jika alamat IP replikasi berubah.
### Konfigurasi dengan beberapa VPCs
Jika titik akhir sumber dan titik akhir target berbeda VPCs, Anda dapat membuat instance replikasi di salah satu. VPCs Anda kemudian dapat menautkan keduanya VPCs dengan menggunakan VPC peering.
Koneksi peering VPC adalah koneksi jaringan antara dua VPCs yang memungkinkan perutean menggunakan alamat IP pribadi masing-masing VPC seolah-olah mereka berada di jaringan yang sama. Anda dapat membuat koneksi peering VPC antara Anda sendiri VPCs, dengan VPC di AWS akun lain, atau dengan VPC di Wilayah yang berbeda. AWS Untuk informasi lebih lanjut mengenai peering VPC, lihat [peering VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) dalam *Panduan Pengguna Amazon VPC*.
Ilustrasi berikut menunjukkan sebuah contoh konfigurasi yang menggunakan peering VPC. Di sini, basis data sumber pada instans Amazon EC2 dalam VPC terhubung ke VPC melalui peering VPC. VPC ini berisi instans replikasi dan basis data target pada instans DB Amazon RDS.
![\[AWS Contoh replikasi Layanan Migrasi Database\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
Untuk menerapkan peering VPC, ikuti petunjuk di Bekerja [dengan koneksi peering VPC yang terletak di Amazon *Virtual Private* Cloud, dokumentasi VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html). Pastikan tabel rute satu VPC berisi blok CIDR yang lain. Misalnya, jika VPC A menggunakan tujuan 10.0.0.0/16 dan VPC B menggunakan destination172.31.0.0, tabel rute VPC A harus berisi 172.31.0.0, dan tabel rute VPC B harus berisi 10.0.0.0/16. Untuk informasi selengkapnya, lihat [Memperbarui tabel rute Anda untuk koneksi peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) di *Amazon Virtual Private Cloud, dokumentasi VPC* Peering.
Grup keamanan VPC yang digunakan dalam konfigurasi ini harus mengizinkan masuknya pada port database dari instance replikasi, atau harus memungkinkan masuknya pada blok CIDR untuk VPC yang diintip.
### Konfigurasi dengan bersama VPCs
AWS DMS memperlakukan subnet yang dibagikan ke akun pelanggan yang berpartisipasi dalam suatu organisasi seperti subnet biasa di akun yang sama. Di bawah ini adalah deskripsi tentang bagaimana AWS DMS menangani VPCs, subnet, dan bagaimana Anda dapat menggunakan shared VPCs.
Anda dapat mengonfigurasi konfigurasi jaringan Anda untuk beroperasi di subnet khusus atau VPCs dengan membuat `ReplicationSubnetGroup` objek. Saat Anda membuat`ReplicationSubnetGroup`, Anda dapat memilih untuk menentukan subnet dari VPC tertentu di akun Anda. Daftar subnet yang Anda tentukan harus menyertakan setidaknya dua subnet yang berada di zona ketersediaan terpisah, dan semua subnet harus berada dalam VPC yang sama. Saat membuat`ReplicationSubnetGroup`, pelanggan hanya menentukan subnet. AWS DMS akan menentukan VPC atas nama Anda, karena setiap subnet ditautkan ke tepat satu VPC.
Saat membuat AWS DMS `ReplicationInstance` atau a AWS DMS `ReplicationConfig`, Anda dapat memilih untuk menentukan Grup Keamanan VPC `ReplicationSubnetGroup` and/or tempat `ReplicationInstance` atau Replikasi Tanpa Server beroperasi. Jika tidak ditentukan, AWS DMS pilih default pelanggan `ReplicationSubnetGroup` (yang AWS DMS dibuat atas nama Anda jika tidak ditentukan untuk semua subnet dalam VPC default) dan Grup Keamanan VPC default.
Anda dapat memilih untuk menjalankan migrasi di zona ketersediaan yang Anda tentukan, atau di salah satu zona ketersediaan di zona ketersediaan. `ReplicationSubnetGroup` Saat AWS DMS mencoba membuat Instance Replikasi atau memulai Replikasi Tanpa Server, itu menerjemahkan zona ketersediaan subnet Anda ke dalam zona ketersediaan di akun layanan inti, untuk memastikan bahwa kami meluncurkan instance di Availability Zone yang benar meskipun pemetaan Availability Zone tidak identik antara kedua akun tersebut.
Jika Anda menggunakan VPC bersama, Anda harus memastikan bahwa Anda membuat `ReplicationSubnetGroup` objek yang dipetakan ke subnet yang ingin Anda gunakan dari VPC bersama. Saat membuat `ReplicationInstance` atau a`ReplicationConfig`, Anda harus menentukan `ReplicationSubnetGroup` untuk VPC bersama, dan menentukan grup keamanan VPC yang Anda buat untuk VPC bersama dengan permintaan Buat.
Perhatikan hal berikut tentang penggunaan VPC bersama:
+ Pemilik VPC tidak dapat berbagi sumber daya dengan peserta, tetapi peserta dapat membuat sumber daya layanan di subnet pemilik.
+ Pemilik VPC tidak dapat mengakses sumber daya (seperti contoh replikasi) yang dibuat oleh peserta, karena semua sumber daya bersifat spesifik akun. Namun, selama Anda membuat instance replikasi di VPC bersama, VPC dapat mengakses sumber daya di VPC terlepas dari akun yang dimilikinya, selama titik akhir atau tugas replikasi memiliki izin yang benar.
+ Karena sumber daya bersifat spesifik akun, peserta lain tidak dapat mengakses sumber daya yang dimiliki oleh akun lain. Tidak ada izin yang dapat Anda berikan kepada akun lain agar mereka dapat mengakses sumber daya yang dibuat di VPC bersama dengan akun Anda.
### Konfigurasi untuk jaringan ke VPC menggunakan Direct Connect atau VPN
Jaringan jarak jauh dapat terhubung ke VPC menggunakan beberapa opsi seperti Direct AWS Connect atau perangkat lunak atau koneksi VPN perangkat keras. Opsi tersebut sering digunakan untuk mengintegrasikan layanan di tempat yang sudah ada, seperti pemantauan, autentikasi, keamanan, data, atau sistem lainnya, dengan memperluas jaringan internal ke AWS cloud. Dengan menggunakan ekstensi jaringan jenis ini, Anda dapat terhubung dengan mulus ke sumber daya yang di-host AWS seperti VPC.
Ilustrasi berikut menunjukkan konfigurasi di mana titik akhir sumber adalah basis data on premise di pusat data perusahaan. Titik akhir terhubung dengan menggunakan Direct Connect atau VPN ke VPC yang berisi instans replikasi dan basis data target pada instans DB Amazon RDS.
![\[AWS Contoh replikasi Layanan Migrasi Database\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-scenarioDirect.png)
Dalam konfigurasi ini, grup keamanan VPC harus menyertakan aturan perutean yang mengirimkan lalu lintas yang ditujukan untuk rentang CIDR VPC atau alamat IP tertentu ke host. Host ini harus dapat menjembatani lalu lintas dari VPC ke VPN on premise. Dalam kasus ini, host NAT mencakup pengaturan grup keamanan sendiri. Pengaturan ini harus memungkinkan lalu lintas dari rentang CIDR VPC instance replikasi, atau alamat IP pribadi, atau grup keamanan ke dalam instance NAT. Tetapi kami tidak menyarankan Anda menggunakan alamat IP pribadi dari contoh replikasi, karena dapat merusak replikasi Anda jika alamat IP replikasi berubah.
### Konfigurasi untuk jaringan ke VPC menggunakan internet
Jika Anda tidak menggunakan VPN atau terhubung Direct Connect ke AWS sumber daya, Anda dapat menggunakan internet untuk memigrasi basis data Anda. Dalam hal ini, Anda dapat bermigrasi ke instans Amazon EC2 atau instans DB Amazon RDS. Konfigurasi ini melibatkan instans replikasi publik di VPC dengan gateway internet yang memuat titik akhir target dan instans replikasi.
![\[AWS Contoh replikasi Layanan Migrasi Database\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-scenarioInternet.png)
Untuk menambahkan gateway internet ke VPC Anda, lihat [Melampirkan gateway internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) di *Panduan Pengguna Amazon VPC*.
Tabel rute VPC harus menyertakan aturan perutean yang mengirim lalu lintas yang tidak ditujukan untuk VPC secara default ke gateway internet. Dalam konfigurasi ini, koneksi ke titik akhir tampaknya datang dari alamat IP publik instans replikasi, bukan alamat IP privat. Untuk informasi lebih lanjut, lihat [Tabel Rute VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) di *Panduan Pengguna Amazon VPC*.
### Konfigurasi dengan instans RDS DB tidak dalam VPC ke instance DB di VPC menggunakan ClassicLink
| |
| --- |
| Kami pensiun EC2-Classic pada 15 Agustus 2022. Kami menyarankan Anda bermigrasi dari EC2-Classic ke VPC. Untuk mengetahui informasi selengkapnya, lihat [Migrasi dari EC2-Classic ke VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) di Panduan Pengguna Amazon EC2 dan blog [Jaringan EC2-Classic akan Segera Dihentikan – Berikut Cara Mempersiapkannya](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/). |
Untuk menghubungkan instans Amazon RDS DB yang tidak dalam VPC ke server replikasi DMS dan instans DB di VPC, Anda dapat menggunakannya dengan server proxy. ClassicLink
ClassicLink memungkinkan Anda untuk menautkan instans EC2-Classic DB ke VPC di akun Anda, dalam Wilayah yang sama. AWS Setelah Anda membuat tautan, instans DB sumber dapat berkomunikasi dengan instans replikasi dalam VPC menggunakan alamat IP privat mereka.
Karena instance replikasi di VPC tidak dapat langsung mengakses instans DB sumber pada platform EC2-Classic, Anda ClassicLink menggunakan server proxy. Server proksi menghubungkan instans DB sumber ke VPC yang memuat instans replikasi dan instans DB target. Server proxy menggunakan ClassicLink untuk terhubung ke VPC. Penerusan port pada server proksi memungkinkan komunikasi antara instans DB sumber dan instans DB target di VPC.
![\[AWS Database Migration Service menggunakan ClassicLink\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### Menggunakan ClassicLink dengan AWS Database Migration Service
Anda dapat menghubungkan instans Amazon RDS DB yang tidak ada dalam VPC ke AWS server replikasi DMS dan instans DB yang ada di VPC. Untuk melakukannya, Anda dapat menggunakan Amazon EC2 ClassicLink dengan server proxy.
Prosedur berikut menunjukkan cara menggunakan ClassicLink untuk tujuan ini. Prosedur ini menghubungkan instans DB sumber Amazon RDS yang tidak ada dalam VPC ke VPC yang berisi AWS instance replikasi DMS dan instans DB target.
+ Buat instance replikasi AWS DMS di VPC. (Semua contoh replikasi dibuat di VPCs.)
+ Kaitkan grup keamanan VPC ke instans replikasi dan instans DB target. Ketika dua instans berbagi grup keamanan VPC, instans tersebut dapat berkomunikasi satu sama lain secara default.
+ Siapkan server proksi pada instans EC2 Classic.
+ Buat koneksi menggunakan ClassicLink antara server proxy dan VPC.
+ Buat titik akhir AWS DMS untuk basis data sumber dan target.
+ Buat tugas AWS DMS.
**Untuk digunakan ClassicLink untuk memigrasikan database pada instance DB bukan di VPC ke database pada instance DB di VPC**
1. Buat instance replikasi AWS DMS dan tetapkan grup keamanan VPC:
1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
Jika Anda masuk sebagai pengguna AWS Identity and Access Management (IAM), pastikan Anda memiliki izin yang sesuai untuk mengakses. AWS DMS Untuk informasi lebih lanjut tentang izin yang diperlukan untuk migrasi basis data, lihat [Izin IAM diperlukan untuk menggunakan AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Pada halaman **Dasbor**, pilih **Instans Replikasi**. Ikuti petunjuk di [Langkah 1: Buat contoh replikasi menggunakan konsol AWS DMS](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance) untuk membuat instans replikasi.
1. Setelah Anda membuat instance replikasi AWS DMS, buka konsol layanan EC2. C **Antarmuka Jaringan** dari panel navigasi.
1. Pilih *DMSNetworkAntarmuka*, lalu pilih **Ubah Grup Keamanan** dari menu **Tindakan**.
1. Pilih grup keamanan yang ingin Anda gunakan untuk instans replikasi dan instans DB target.
1. Kaitkan grup keamanan dari langkah terakhir dengan instans DB target:
1. Buka konsol layanan Amazon RDS. Pilih **Instans** dari panel navigasi.
1. Pilih instans DB target. Untuk **Tindakan Instans**, pilih **Ubah**.
1. Untuk parameter **Grup Keamanan**, pilih grup keamanan yang Anda gunakan pada langkah sebelumnya.
1. Pilih **Lanjutkan**, dan kemudian **Ubah Instans DB**.
1. Langkah 3: Siapkan server proksi pada instans EC2 Classic menggunakan NGINX. Gunakan AMI pilihan Anda untuk meluncurkan instans EC2 Classic. Contoh di bawah ini didasarkan pada AMI Ubuntu Server 14.04 LTS (HVM).
Untuk menyiapkan server proksi pada instans EC2 Classic
1. Hubungkan ke instans EC2 Classic dan instal NGINX menggunakan perintah berikut:
```
Prompt> sudo apt-get update
Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz
Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz
Prompt> cd nginx-1.9.12
Prompt> sudo apt-get install build-essential
Prompt> sudo apt-get install libpcre3 libpcre3-dev
Prompt> sudo apt-get install zlib1g-dev
Prompt> sudo ./configure --with-stream
Prompt> sudo make
Prompt> sudo make install
```
1. Edit file daemon NGINX, `/etc/init/nginx.conf`, menggunakan kode berikut:
```
# /etc/init/nginx.conf – Upstart file
description "nginx http daemon"
author "email"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
env DAEMON=/usr/local/nginx/sbin/nginx
env PID=/usr/local/nginx/logs/nginx.pid
expect fork
respawn
respawn limit 10 5
pre-start script
$DAEMON -t
if [ $? -ne 0 ]
then exit $?
fi
end script
exec $DAEMON
```
1. Buat file konfigurasi NGINX di `/usr/local/nginx/conf/nginx.conf`. Di file konfigurasi, tambahkan berikut ini:
```
# /usr/local/nginx/conf/nginx.conf - NGINX configuration file
worker_processes 1;
events {
worker_connections 1024;
}
stream {
server {
listen DB instance port number;
proxy_pass DB instance identifier:DB instance port number;
}
}
```
1. Dari baris perintah, mulai NGINX menggunakan perintah berikut:
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. Buat ClassicLink koneksi antara server proxy dan VPC target yang berisi instans DB target dan instance replikasi:
1. Buka konsol EC2 dan pilih instans EC2 Classic yang menjalankan server proksi.
1. Untuk **Tindakan**, pilih **ClassicLink**, lalu pilih **Tautkan ke VPC**.
1. Pilih grup keamanan yang Anda gunakan sebelumnya dalam prosedur ini.
1. Pilih **Tautkan ke VPC**.
1. Langkah 5: Buat titik akhir AWS DMS menggunakan prosedur di. [Langkah 2: Tentukan titik akhir sumber dan target](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints) Pastikan untuk menggunakan nama host DNS EC2 internal dari proksi sebagai nama server saat menentukan titik akhir sumber.
1. Buat tugas AWS DMS menggunakan prosedur di[Langkah 3: Buat tugas dan migrasi data](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks).
### Konfigurasi untuk jaringan yang terhubung ke AWS layanan
Untuk terhubung dengan AWS layanan, gunakan koneksi internet atau titik akhir Virtual Private Cloud (VPC). Ini berlaku ketika:
Sumber atau titik akhir target Anda menggunakan AWS layanan seperti:
+ AWS Secrets Manager
+ Amazon Simple Storage Service
Titik akhir target Anda adalah AWS layanan seperti:
+ Amazon S3
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ OpenSearch Layanan Amazon
+ Amazon Athena
### Konfigurasi untuk jaringan yang terhubung ke AWS layanan menggunakan titik akhir VPC
Titik akhir VPC menyediakan koneksi aman antara AWS sumber daya Anda, menghubungkan sumber daya VPC ke AWS layanan tanpa memerlukan akses internet. Aplikasi Anda di subnet pribadi dapat mengakses AWS layanan sambil tetap berada dalam AWS jaringan, meningkatkan keamanan dan mengurangi latensi. Silakan lihat gambar di bawah ini:
![\[\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
Untuk informasi selengkapnya, lihat [Mengonfigurasi titik akhir VPC AWS DMS sebagai titik akhir sumber dan target serta](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) [Mengonfigurasi AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html) manajer rahasia VPC Endpoint.
### Konfigurasi untuk jaringan yang terhubung ke AWS layanan menggunakan internet
Instance replikasi membutuhkan akses internet untuk terhubung dengan AWS sumber daya selama migrasi data.
Untuk informasi selengkapnya mengenai subnet pribadi dan publik dalam VPC, [lihat Contoh: VPC dengan server di subnet pribadi dan NAT di Panduan Pengguna Amazon](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) Virtual Private *Cloud*. Anda harus memastikan untuk menguji konfigurasi jaringan Anda untuk konektivitas dengan layanan apa pun yang diperlukan.
## Membuat grup subnet replikasi
Sebagai bagian dari jaringan yang akan digunakan untuk migrasi database, Anda perlu menentukan subnet mana di virtual private cloud (VPC) yang akan Anda gunakan. VPC tersebut harus berdasarkan layanan Amazon VPC. *Subnet* adalah serangkaian alamat IP di VPC Anda dalam Availability Zone tertentu. Subnet ini dapat didistribusikan di antara Availability Zones untuk AWS Wilayah tempat VPC Anda berada.
Saat membuat instance replikasi atau profil instans di konsol AWS DMS, Anda dapat menggunakan subnet yang Anda pilih.
Anda membuat grup subnet replikasi untuk menentukan subnet mana yang digunakan. Anda harus menentukan subnet di setidaknya dua Availability Zone.
**Untuk membuat grup subnet replikasi**
1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
Jika Anda masuk sebagai pengguna IAM, pastikan Anda memiliki izin yang sesuai untuk mengakses AWS DMS. Untuk informasi lebih lanjut tentang izin yang diperlukan untuk migrasi basis data, lihat [Izin IAM diperlukan untuk menggunakan AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Di panel navigasi, pilih **Grup Subnet**.
1. Pilih **Buat grup subnet**.
1. Pada halaman **grup subnet Buat replikasi, tentukan informasi grup** subnet replikasi Anda. Tabel berikut menjelaskan pengaturan.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. Pilih **Buat grup subnet**.
## Menyelesaikan titik akhir domain menggunakan DNS
Biasanya, instance AWS DMS replikasi menggunakan resolver Domain Name System (DNS) dalam instans Amazon EC2 untuk menyelesaikan titik akhir domain. Jika Anda memerlukan resolusi DNS, Anda dapat menggunakan Amazon Route 53 Resolver. Untuk informasi lebih lanjut tentang penggunaan Route 53 DNS Resolver, lihat [Memulai dengan Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html).
Untuk informasi tentang cara menggunakan server nama on premise Anda sendiri untuk menyelesaikan titik akhir tertentu menggunakan Amazon Route 53 Resolver, lihat [Menggunakan server nama on-premise Anda sendiri](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
# Mengatur kunci enkripsi untuk instans replikasi
AWS DMS mengenkripsi penyimpanan yang digunakan oleh contoh replikasi dan informasi koneksi titik akhir. Untuk mengenkripsi penyimpanan yang digunakan oleh instance replikasi, AWS DMS menggunakan AWS KMS key yang unik untuk akun Anda. AWS Anda dapat melihat dan mengelola kunci KMS ini dengan AWS Key Management Service (AWS KMS). Anda dapat menggunakan kunci KMS default di akun (`aws/dms`) atau kunci KMS yang Anda buat. Jika Anda memiliki kunci AWS KMS enkripsi yang ada, Anda juga dapat menggunakan kunci itu untuk enkripsi.
Anda dapat menentukan kunci enkripsi Anda sendiri dengan menyediakan pengenal kunci KMS untuk mengenkripsi sumber daya DMS Anda. AWS Bila Anda menentukan kunci enkripsi Anda sendiri, akun pengguna yang digunakan untuk melakukan migrasi basis data harus memiliki akses ke kunci tersebut. Untuk informasi lebih lanjut tentang membuat kunci enkripsi Anda sendiri dan memberikan akses ke kunci enkripsi kepada pengguna, lihat *[Panduan Developer AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*.
Jika Anda tidak menentukan pengenal kunci KMS, maka AWS DMS menggunakan kunci enkripsi default Anda. KMS membuat kunci enkripsi default untuk AWS DMS untuk akun Anda AWS . AWS Akun Anda memiliki kunci enkripsi default yang berbeda untuk setiap AWS Wilayah.
Untuk mengelola kunci yang digunakan untuk mengenkripsi sumber daya AWS DMS Anda, Anda gunakan. AWS KMS Anda dapat menemukan AWS KMS di Konsol Manajemen AWS dengan mencari **KMS** pada panel navigasi.
AWS KMS menggabungkan perangkat keras dan perangkat lunak yang aman dan sangat tersedia untuk menyediakan sistem manajemen kunci yang diskalakan untuk cloud. Dengan menggunakan AWS KMS, Anda dapat membuat kunci enkripsi dan menentukan kebijakan yang mengontrol bagaimana kunci ini dapat digunakan. AWS KMS mendukung AWS CloudTrail, sehingga Anda dapat mengaudit penggunaan kunci untuk memverifikasi bahwa kunci sedang digunakan dengan tepat. AWS KMS Kunci Anda dapat digunakan dalam kombinasi dengan AWS DMS dan AWS layanan lain yang didukung. Layanan AWS yang didukung termasuk Amazon RDS, Amazon S3, Amazon Elastic Block Store (Amazon EBS), dan Amazon Redshift.
Ketika Anda telah membuat sumber daya AWS DMS Anda dengan kunci enkripsi tertentu, Anda tidak dapat mengubah kunci enkripsi untuk sumber daya tersebut. Pastikan untuk menentukan persyaratan kunci enkripsi Anda sebelum Anda membuat sumber daya AWS DMS Anda.
# Membuat instans replikasi
Tugas pertama Anda dalam migrasi basis data adalah membuat instans replikasi. Instans replikasi tersebut memerlukan daya penyimpanan dan pemrosesan yang cukup untuk melakukan tugas yang Anda tetapkan dan memigrasi data dari basis data sumber Anda ke basis data target. Ukuran yang diperlukan dari instans ini bervariasi tergantung pada jumlah data yang perlu Anda migrasi dan tugas yang perlu dilakukan instans tersebut. Untuk informasi selengkapnya tentang instans replikasi, lihat [Bekerja dengan instance AWS DMS replikasi](CHAP_ReplicationInstance.md).
**Untuk membuat instance replikasi dengan menggunakan konsol AWS**
1. Pilih **contoh replikasi** di panel navigasi AWS DMS konsol dan kemudian pilih **Buat** instance replikasi.
1. Pada halaman **Buat instans replikasi**, tentukan informasi instans replikasi Anda. Tabel berikut menjelaskan pengaturan yang dapat Anda buat.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Pilih tab **Lanjutan** untuk mengatur nilai pengaturan jaringan dan enkripsi jika Anda membutuhkannya. Tabel berikut menjelaskan pengaturan.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Tentukan pengaturan **Pemeliharaan**. Tabel berikut menjelaskan pengaturan. Untuk informasi lebih lanjut tentang pengaturan pemeliharaan, lihat [Bekerja dengan jendela AWS DMS pemeliharaan](CHAP_ReplicationInstance.MaintenanceWindow.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Pilih **Buat instans replikasi**.
# Mengubah instans replikasi
Anda dapat mengubah pengaturan untuk instans replikasi, misalnya untuk mengubah kelas instans atau untuk meningkatkan penyimpanan.
Saat Anda mengubah instans replikasi, Anda dapat segera menerapkan perubahan. Untuk segera menerapkan perubahan, pilih opsi **Langsung terapkan perubahan** pada Konsol Manajemen AWS. Atau gunakan `--apply-immediately` parameter saat memanggil AWS CLI, atau atur `ApplyImmediately` parameter ke `true` saat menggunakan DMS API.
Jika Anda tidak memilih untuk menerapkan perubahan dengan serta-merta, perubahan akan dimasukkan ke dalam antrean perubahan yang tertunda. Selama jendela pemeliharaan berikutnya, perubahan yang tertunda di antrean akan diterapkan.
**catatan**
Jika Anda memilih untuk menerapkan perubahan dengan segera, perubahan apa pun pada antrean modifikasi yang tertunda juga akan diterapkan. Jika salah satu dari modifikasi yang tertunda memerlukan waktu henti, memilih **Langsung terapkan perubahan** dapat menyebabkan waktu henti yang tidak terduga.
**Untuk memodifikasi instance replikasi dengan menggunakan konsol AWS**
1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Di panel navigasi, pilih **Instans replikasi**.
1. Pilih instans replikasi yang ingin Anda ubah. Tabel berikut menjelaskan perubahan yang dapat Anda lakukan.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## Praktik terbaik saat memodifikasi instance replikasi
Saat memodifikasi instance replikasi, mengikuti praktik terbaik ini membantu memastikan pembaruan yang berhasil dengan dampak minimal pada alur kerja migrasi Anda. Ambil langkah-langkah kunci berikut sebelum, selama, dan setelah modifikasi untuk menjaga integritas data dan efisiensi operasional selama proses berlangsung.
**Rencanakan waktu modifikasi:**
+ Anda dapat segera menerapkan perubahan atau menjadwalkannya untuk jendela pemeliharaan berikutnya.
+ Jadwalkan selama periode lalu lintas rendah untuk meminimalkan dampak.
**Langkah-langkah pra-modifikasi:**
+ Hentikan semua tugas replikasi aktif.
+ Verifikasi semua tugas telah berhasil dihentikan.
+ Dokumentasikan pengaturan tugas konfigurasi saat ini.
**Selama modifikasi:**
+ Pantau kemajuan modifikasi.
+ Tunggu status “Tersedia” sebelum melanjutkan.
**Langkah pasca-modifikasi:**
+ Lanjutkan semua tugas yang dihentikan sebelumnya.
+ Konfirmasikan tugas berjalan dengan benar.
# Mem-boot ulang instans replikasi
Anda dapat me-reboot instance AWS DMS replikasi untuk me-restart mesin replikasi. Boot ulang akan menyebabkan instans replikasi mati sementara, selama status instans diatur ke **Bootulang**. Jika AWS DMS instance dikonfigurasi untuk Multi-AZ, reboot dapat dilakukan dengan failover. AWS DMS Peristiwa dibuat saat reboot selesai.
Jika AWS DMS instans Anda adalah penerapan Multi-AZ, Anda dapat memaksa failover yang direncanakan dari satu AWS Availability Zone ke Availability Zone lainnya saat melakukan reboot. Bila Anda memaksa failover terencana dari AWS DMS instans Anda, AWS DMS menutup koneksi aktif pada instance saat ini sebelum secara otomatis beralih ke instans siaga di Availability Zone lain. Mem-boot ulang dengan failover terencana membantu Anda mensimulasikan peristiwa failover yang direncanakan dari sebuah AWS DMS instance, seperti saat menskalakan kelas instance replikasi.
**catatan**
Setelah boot ulang memaksa failover dari satu Availability Zone ke lainnya, perubahan Availability Zone mungkin tidak tercermin selama beberapa menit. Kelambatan ini muncul di Konsol Manajemen AWS, dan dalam panggilan ke AWS CLI dan AWS DMS API.
Jika tugas migrasi berjalan pada instance replikasi saat reboot terjadi, tidak ada kehilangan data yang terjadi tetapi tugas berhenti, dan status tugas berubah menjadi status kesalahan.
Jika tabel dalam tugas migrasi berada di tengah beban massal (fase beban penuh) dan belum dimulai, tabel tersebut masuk ke status kesalahan. Tetapi tabel yang lengkap pada saat itu, tetap dalam keadaan lengkap. Ketika reboot terjadi selama fase beban penuh, kami sarankan Anda melakukan salah satu langkah di bawah ini.
+ Hapus tabel yang berada dalam keadaan lengkap dari tugas, dan mulai ulang tugas dengan tabel yang tersisa.
+ Buat tugas baru dengan tabel dalam keadaan kesalahan, dan dengan tabel yang tertunda.
Jika tabel dalam tugas migrasi berada dalam fase replikasi yang sedang berlangsung, tugas dilanjutkan setelah boot ulang selesai.
Anda tidak dapat me-reboot instance AWS DMS replikasi Anda jika statusnya tidak dalam status **Tersedia**. AWS DMS Instance Anda mungkin tidak tersedia karena beberapa alasan, seperti modifikasi yang diminta sebelumnya atau tindakan jendela pemeliharaan. Waktu yang diperlukan untuk me-reboot instance AWS DMS replikasi biasanya kecil (di bawah 5 menit).
## Mem-boot ulang instance replikasi menggunakan konsol AWS
Untuk me-reboot instance replikasi, gunakan AWS konsol.
**Untuk me-reboot instance replikasi menggunakan konsol AWS**
1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Di panel navigasi, pilih **Instans replikasi**.
1. Pilih instans replikasi yang ingin Anda boot ulang.
1. Pilih **Boot ulang**. Kotak dialog **contoh replikasi Reboot** terbuka.
1. Pilih kotak centang untuk **Reboot dengan failover yang direncanakan**? jika Anda telah mengonfigurasi instance replikasi untuk penerapan Multi-AZ dan Anda ingin gagal ke Availability Zone lain AWS .
1. Pilih **Boot ulang**.
## Mem-boot ulang instans replikasi menggunakan CLI
Untuk me-reboot instance replikasi, gunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html)perintah dengan parameter berikut:
+ `--replication-instance-arn`
**Example Contoh boot ulang sederhana**
AWS CLI Contoh berikut reboot instance replikasi.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance
```
**Example Contoh boot ulang sederhana dengan failover**
AWS CLI Contoh berikut me-reboot instance replikasi dengan failover.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## Mem-boot ulang instans replikasi menggunakan API
Untuk me-reboot instance replikasi, gunakan [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)aksi AWS DMS API dengan parameter berikut:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Contoh boot ulang sederhana**
Contoh kode berikut mem-boot ulang instans replikasi.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
**Example Contoh boot ulang sederhana dengan failover**
Contoh kode berikut me-reboot instance replikasi dan gagal ke AWS Availability Zone lain.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &ForcePlannedFailover=true
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Menghapus instans replikasi
Anda dapat menghapus contoh AWS DMS replikasi ketika Anda selesai menggunakannya. Jika Anda memiliki tugas migrasi yang menggunakan instans replikasi, Anda harus menghentikan dan menghapus tugas-tugas tersebut sebelum menghapus instans replikasi.
Jika Anda menutup AWS akun, semua AWS DMS sumber daya dan konfigurasi yang terkait dengan akun Anda akan dihapus setelah dua hari. Sumber daya tersebut mencakup semua instans replikasi, konfigurasi titik akhir sumber dan target, tugas replikasi, dan sertifikat SSL. Jika setelah dua hari Anda memutuskan untuk menggunakan AWS DMS lagi, Anda membuat ulang sumber daya yang Anda butuhkan.
Jika instans replikasi Anda memenuhi semua kriteria untuk penghapusan, dan tetap dalam `DELETING` status untuk jangka waktu yang lama, hubungi dukungan untuk memecahkan masalah.
## Menghapus instance replikasi menggunakan konsol AWS
Untuk menghapus instance replikasi, gunakan AWS konsol.
**Untuk menghapus instance replikasi menggunakan konsol AWS**
1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Di panel navigasi, pilih **Instans replikasi**.
1. Pilih instans replikasi yang ingin dihapus.
1. Pilih **Hapus**.
1. Di kotak dialog, pilih **Hapus**.
## Menghapus instans replikasi menggunakan CLI
Untuk menghapus contoh replikasi, gunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html)perintah dengan parameter berikut:
+ `--replication-instance-arn`
**Example Contoh hapus**
AWS CLI Contoh berikut menghapus contoh replikasi.
```
aws dms delete-replication-instance \
--replication-instance-arn arn of my rep instance
```
## Menghapus instans replikasi menggunakan API
Untuk menghapus instance replikasi, gunakan [https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)aksi AWS DMS API dengan parameter berikut:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Contoh hapus**
Contoh kode berikut menghapus instans replikasi.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=DeleteReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Bekerja dengan jendela AWS DMS pemeliharaan
Setiap contoh AWS DMS replikasi memiliki jendela pemeliharaan mingguan di mana setiap perubahan sistem yang tersedia diterapkan. Anda dapat menganggap jendela pemeliharaan sebagai peluang untuk mengontrol ketika modifikasi dan patching perangkat lunak terjadi.
Jika AWS DMS menentukan bahwa pemeliharaan diperlukan selama minggu tertentu, pemeliharaan terjadi selama jendela pemeliharaan 30 menit yang Anda pilih saat Anda membuat instance replikasi. AWS DMS menyelesaikan sebagian besar perawatan selama jendela pemeliharaan 30 menit. Namun, waktu yang lebih lama mungkin diperlukan untuk perubahan yang lebih besar.
## Pengaruh pemeliharaan pada tugas migrasi yang ada
Saat tugas AWS DMS migrasi berjalan pada sebuah instance, peristiwa berikut terjadi saat tambalan diterapkan:
+ Jika tabel dalam tugas migrasi berada dalam fase mereplikasi perubahan berkelanjutan (CDC), AWS DMS hentikan tugas sejenak dan kemudian lanjutkan setelah tambalan diterapkan. Migrasi kemudian berlanjut dari tempat di mana migrasi terganggu ketika patch diterapkan.
+ Jika AWS DMS memigrasikan tabel sebagai bagian dari **migrasi data yang ada atau memigrasikan data yang** **ada dan mereplikasi tugas perubahan yang sedang berlangsung**, DMS berhenti dan kemudian memulai ulang migrasi untuk semua tabel yang berada dalam fase pemuatan penuh saat tambalan diterapkan. DMS juga berhenti dan melanjutkan semua tabel yang berada dalam fase CDC saat patch diterapkan.
## Mengubah pengaturan jendela pemeliharaan
Anda dapat mengubah kerangka waktu jendela pemeliharaan menggunakan Konsol Manajemen AWS, AWS CLI, atau AWS DMS API.
### Mengubah pengaturan jendela pemeliharaan menggunakan konsol
Anda dapat mengubah jangka waktu jendela pemeliharaan menggunakan Konsol Manajemen AWS.
**Untuk mengubah jendela pemeliharaan yang diinginkan menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Di panel navigasi, pilih **Instans replikasi**.
1. Pilih instans replikasi yang ingin Anda ubah dan pilih **Modifikasi**.
1. Perluas tab **Pemeliharaan** dan pilih tanggal dan waktu untuk jendela pemeliharaan Anda.
1. Pilih **Langsung terapkan perubahan**.
1. Pilih **Modifikasi**.
### Mengubah pengaturan jendela pemeliharaan menggunakan CLI
Untuk menyesuaikan jendela pemeliharaan yang disukai, gunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)perintah dengan parameter berikut.
+ `--replication-instance-identifier`
+ `--preferred-maintenance-window`
**Example**
AWS CLI Contoh berikut menetapkan jendela pemeliharaan ke hari Selasa dari pukul 4:00 - 4:30 pagi. UTC.
```
aws dms modify-replication-instance \
--replication-instance-identifier myrepinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
### Mengubah pengaturan jendela pemeliharaan menggunakan API
Untuk menyesuaikan jendela pemeliharaan yang diinginkan, gunakan [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)tindakan AWS DMS API dengan parameter berikut.
+ `ReplicationInstanceIdentifier = myrepinstance`
+ `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30`
**Example**
Contoh kode berikut mengatur jendela pemeliharaan ke Selasa mulai 4:00-4:30 pagi. UTC.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=ModifyReplicationInstance
3. &DBInstanceIdentifier=myrepinstance
4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```