Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Anda dapat menggunakan Migrasi data homogen 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_dump 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_restore 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.

Praktik terbaik untuk menggunakan database PostgreSQL sebagai sumber migrasi data homogen
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_logical_replication_workers - Menentukan jumlah maksimum pekerja replikasi logis. Ini termasuk pekerja terapan di sisi pelanggan dan pekerja sinkronisasi tabel.
max_sync_workers_per_subscription — 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 melebihimax_worker_processes
, danmax_sync_workers_per_subscription
harus kurang dari atau sama denganmax_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.