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

# Migrasi data dari database PostgreSQL dengan migrasi data homogen di AWS DMS
<a name="dm-migrating-data-postgresql"></a>

Anda dapat menggunakan [Migrasi data homogen](data-migrations.md) untuk memigrasikan database PostgreSQL yang dikelola sendiri ke RDS untuk PostgreSQL atau Aurora PostgreSQL. AWS DMS menciptakan lingkungan tanpa server untuk migrasi data Anda. Untuk berbagai jenis migrasi data, AWS DMS gunakan alat database PostgreSQL asli yang berbeda.

Untuk migrasi data homogen dari tipe **Full load**, AWS DMS gunakan pg\$1dump untuk membaca data dari database sumber Anda dan menyimpannya di disk yang terpasang ke lingkungan tanpa server. Setelah AWS DMS membaca semua data sumber Anda, ia menggunakan pg\$1restore di database target untuk memulihkan data Anda.

Untuk migrasi data homogen dari tipe **Full load and change data capture (CDC)**, AWS DMS gunakan `pg_dump` untuk membaca objek skema tanpa data tabel dari database sumber Anda dan menyimpannya di disk yang terpasang ke lingkungan tanpa server. Kemudian digunakan `pg_restore` dalam database target untuk mengembalikan objek skema Anda. Setelah AWS DMS menyelesaikan `pg_restore` proses, secara otomatis beralih ke model penerbit dan pelanggan untuk replikasi logis dengan `Initial Data Synchronization` opsi untuk menyalin data tabel awal langsung dari database sumber ke database target, dan kemudian memulai replikasi yang sedang berlangsung. Dalam model ini, satu atau lebih pelanggan berlangganan satu atau lebih publikasi pada node penerbit.

Untuk migrasi data homogen tipe **Change data capture (CDC)**, AWS DMS memerlukan titik awal asli untuk memulai replikasi. Jika Anda memberikan titik awal asli, maka AWS DMS menangkap perubahan dari titik itu. Atau, pilih **Segera** di pengaturan migrasi data untuk secara otomatis menangkap titik awal replikasi saat migrasi data aktual dimulai.

**catatan**  
Agar migrasi khusus CDC berfungsi dengan baik, semua skema dan objek basis data sumber harus sudah ada di database target. Target mungkin memiliki objek yang tidak ada pada sumbernya.

Anda dapat menggunakan contoh kode berikut untuk mendapatkan titik awal asli dalam database PostgreSQL Anda.

```
select confirmed_flush_lsn from pg_replication_slots where slot_name=‘migrate_to_target';
```

Kueri ini menggunakan `pg_replication_slots` tampilan dalam database PostgreSQL Anda untuk menangkap nilai nomor urutan log (LSN).

Setelah AWS DMS menyetel status migrasi data homogen PostgreSQL Anda **ke** Dihentikan**, Gagal, **atau** Dihapus,** penerbit dan replikasi tidak akan dihapus. Jika Anda tidak ingin melanjutkan migrasi, hapus slot replikasi dan penerbit dengan menggunakan perintah berikut.

```
SELECT pg_drop_replication_slot('migration_subscriber_{ARN}');
            DROP PUBLICATION publication_{ARN};
```

Diagram berikut menunjukkan proses menggunakan migrasi data homogen untuk memigrasikan database PostgreSQL AWS DMS ke RDS untuk PostgreSQL atau Aurora PostgreSQL.

![\[Diagram arsitektur migrasi data PostgreSQL dengan Migrasi Data Homogen DMS.\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/data-migrations-postgresql.png)


## Praktik terbaik untuk menggunakan database PostgreSQL sebagai sumber migrasi data homogen
<a name="dm-migrating-data-postgresql.bp"></a>
+ Untuk mempercepat sinkronisasi data awal di sisi pelanggan untuk tugas FLCDC, Anda harus menyesuaikan dan. `max_logical_replication_workers` `max_sync_workers_per_subscription` Meningkatkan nilai-nilai ini meningkatkan kecepatan sinkronisasi tabel.
  + **max\$1logical\$1replication\$1workers - Menentukan jumlah maksimum pekerja replikasi** logis. Ini termasuk pekerja terapan di sisi pelanggan dan pekerja sinkronisasi tabel. 
  + **max\$1sync\$1workers\$1per\$1subscription** — Peningkatan hanya `max_sync_workers_per_subscription` mempengaruhi jumlah tabel yang disinkronkan secara paralel, bukan jumlah pekerja per tabel.
**catatan**  
`max_logical_replication_workers`tidak boleh melebihi`max_worker_processes`, dan `max_sync_workers_per_subscription` harus kurang dari atau sama dengan`max_logical_replication_workers`.
+ Untuk memigrasikan tabel besar, pertimbangkan untuk membaginya menjadi tugas terpisah menggunakan aturan pemilihan. Misalnya, Anda dapat membagi tabel besar menjadi tugas individual yang terpisah dan tabel kecil menjadi tugas tunggal lainnya.
+ Pantau penggunaan disk dan CPU di sisi pelanggan untuk mempertahankan kinerja optimal.