Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Anda dapat memigrasikan data dari satu atau banyak database PostgreSQL menggunakan. AWS DMS Dengan database PostgreSQL sebagai sumber, Anda dapat memigrasikan data ke database PostgreSQL lain atau salah satu database lain yang didukung.
Untuk informasi tentang versi PostgreSQL AWS DMS yang mendukung sebagai sumber, lihat. Sumber untuk AWS DMS
AWS DMS mendukung PostgreSQL untuk jenis database ini:
-
Basis data on-premise
-
Database pada instans Amazon EC2
-
Basis data pada instans DB Amazon RDS
-
Basis data pada instans DB berdasarkan Amazon Aurora Edisi Kompatibel PostgreSQL
-
Database pada instans DB berdasarkan Amazon Aurora PostgreSQL yang kompatibel dengan Serverless Edition
catatan
DMS mendukung Amazon Aurora PostgreSQL — V1 tanpa server sebagai sumber untuk Full load saja. Tetapi Anda dapat menggunakan Amazon Aurora PostgreSQL—Serverless V2 sebagai sumber untuk tugas Full load, Full load+CDC, dan CDC saja.
Versi sumber PostgreSQL |
AWS DMS versi yang akan digunakan |
---|---|
9.x, 10.x, 11.x, 12.x |
Gunakan AWS DMS versi apa pun yang tersedia. |
13.x |
Gunakan AWS DMS versi 3.4.3 dan lebih tinggi. |
14,x |
Gunakan AWS DMS versi 3.4.7 dan lebih tinggi. |
15,x |
Gunakan AWS DMS versi 3.5.1 dan lebih tinggi. |
16,x |
Gunakan AWS DMS versi 3.5.3 dan lebih tinggi. |
Anda dapat menggunakan Lapisan Soket Aman (SSL) untuk mengenkripsi sambungan antara titik akhir PostgreSQL Anda dan instans replikasi. Untuk informasi selengkapnya tentang penggunaan SSL dengan titik akhir PostgreSQL, lihat Menggunakan SSL dengan AWS Database Migration Service.
Sebagai persyaratan keamanan tambahan saat menggunakan PostgreSQL sebagai sumber, akun pengguna yang ditentukan harus menjadi pengguna terdaftar di basis data PostgreSQL.
Untuk mengonfigurasi database PostgreSQL sebagai titik akhir sumber, lakukan hal AWS DMS berikut:
-
Buat pengguna PostgreSQL dengan izin yang sesuai untuk menyediakan AWS DMS akses ke database sumber PostgreSQL Anda.
catatan
-
Jika basis data sumber PostgreSQL Anda dikelola sendiri, lihatBekerja dengan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS untuk informasi lebih lanjut.
-
Jika basis data sumber PostgreSQL Anda dikelola oleh Amazon RDS, lihat Bekerja dengan database PostgreSQL AWS-managed sebagai sumber DMS untuk informasi lebih lanjut.
-
-
Buat titik akhir sumber PostgreSQL yang sesuai dengan konfigurasi basis data PostgreSQL yang Anda pilih.
-
Buat tugas atau serangkaian tugas untuk memigrasi tabel Anda.
Untuk membuat full-load-only tugas, tidak diperlukan konfigurasi titik akhir lebih lanjut.
Sebelum Anda membuat tugas untuk change data capture (tugas CDC saja atau tugas beban penuh dan CDC), lihat Mengaktifkan CDC menggunakan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMSatau Mengaktifkan CDC dengan instans PostgreSQL DB AWS-managed dengan AWS DMS.
Topik
Bekerja dengan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS
Bekerja dengan database PostgreSQL AWS-managed sebagai sumber DMS
Mengaktifkan change data capture (CDC) menggunakan replikasi logis
Menggunakan titik awal CDC asli untuk mengatur beban CDC dari sumber PostgreSQL
Bermigrasi dari Babelfish untuk Amazon Aurora PostgreSQL menggunakan AWS DMS
Pengaturan konfigurasi tambahan ketika menggunakan basis data PostgreSQL sebagai sumber DMS
Menggunakan pengaturan titik akhir MapBooleanAsBoolean PostgreSQL
Keterbatasan menggunakan basis data PostgreSQL sebagai sumber DMS
Bekerja dengan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS
Dengan database PostgreSQL yang dikelola sendiri sebagai sumber, Anda dapat memigrasikan data ke database PostgreSQL lain, atau salah satu database target lain yang didukung oleh. AWS DMS Sumber database dapat berupa database lokal atau mesin yang dikelola sendiri yang berjalan pada instans Amazon EC2 . Anda dapat menggunakan instans DB untuk baik tugas beban penuh maupun tugas chane data capture (CDC).
Prasyarat untuk menggunakan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS
Sebelum memigrasi data dari basis data sumber PostgreSQL yang dikelola sendiri, lakukan hal berikut:
-
Pastikan Anda menggunakan database PostgreSQL yang versi 9.4.x atau lebih tinggi.
-
Untuk tugas beban penuh plus tugas CDC atau tugas CDC saja, berikan izin pengguna super untuk akun pengguna yang ditentukan untuk basis data sumber PostgreSQL. Akun pengguna membutuhkan izin pengguna super untuk mengakses fungsi khusus replikasi dalam sumber. Untuk tugas beban penuh beban saja, akun pengguna perlu izin SELECT pada tabel untuk memigrasikannya.
-
Tambahkan alamat IP server AWS DMS replikasi ke file
pg_hba.conf
konfigurasi dan aktifkan replikasi dan koneksi soket. Berikut contohnya.# Replication Instance host all all 12.3.4.56/00 md5 # Allow replication connections from localhost, by a user with the # replication privilege. host replication dms 12.3.4.56/00 md5
File konfigurasi
pg_hba.conf
PostgreSQL mengontrol autentikasi klien. (HBA adalah singkatan dari host-based authentication.) File secara tradisional disimpan dalam direktori data klaster basis data. -
Jika Anda mengonfigurasi database sebagai sumber replikasi logis menggunakan lihat AWS DMS Mengaktifkan CDC menggunakan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS
catatan
Beberapa AWS DMS transaksi menganggur selama beberapa waktu sebelum mesin DMS menggunakannya lagi. Dengan menggunakan parameter idle_in_transaction_session_timeout
di PostgreSQL versi 9.6 dan yang lebih tinggi, Anda dapat menyebabkan transaksi idle habis dan gagal. Jangan mengakhiri transaksi yang diam saat Anda menggunakan AWS DMS.
Mengaktifkan CDC menggunakan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS
AWS DMS mendukung pengambilan data perubahan (CDC) menggunakan replikasi logis. Untuk mengaktifkan replikasi logis dari basis data sumber PostgreSQL yang dikelola sendiri, tetapkan parameter dan nilai berikut di file postgresql.conf
konfigurasi:
-
Tetapkan
wal_level = logical
. -
Tetapkan
max_replication_slots
untuk nilai yang lebih besar dari 1.Tetapkan nilai
max_replication_slots
sesuai dengan jumlah tugas yang ingin Anda jalankan. Misalnya, untuk menjalankan lima tugas Anda menetapkan minimal lima slot. Slot terbuka secara otomatis segera setelah tugas dimulai dan tetap terbuka bahkan ketika tugas tidak lagi berjalan. Pastikan Anda menghapus slot terbuka secara manual. Perhatikan bahwa DMS secara otomatis menjatuhkan slot replikasi ketika tugas dihapus, jika DMS membuat slot. -
Atur
max_wal_senders
menjadi nilai yang lebih besar dari 1.Parameter
max_wal_senders
mengatur jumlah tugas bersamaan yang dapat berjalan. -
Parameter
wal_sender_timeout
mengakhiri sambungan replikasi yang tidak aktif lebih lama dari jumlah milidetik tertentu. Default untuk database PostgreSQL lokal adalah 60000 milidetik (60 detik). Menyetel nilai ke 0 (nol) menonaktifkan mekanisme batas waktu, dan merupakan pengaturan yang valid untuk DMS.Saat menyetel
wal_sender_timeout
ke nilai bukan nol, tugas DMS dengan CDC membutuhkan minimal 10.000 milidetik (10 detik), dan gagal jika nilainya kurang dari 10.000. Jaga nilai kurang dari 5 menit untuk menghindari penundaan selama failover multi-AZ dari instance replikasi DMS.
Beberapa parameter bersifat statis, dan Anda hanya dapat mengaturnya pada awal server. Setiap perubahan pada entri mereka dalam file konfigurasi (untuk database yang dikelola sendiri) atau grup parameter DB (untuk RDS untuk database PostgreSQL) diabaikan sampai server dimulai ulang. Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL
Untuk informasi lebih lanjut tentang pengaktifan CDC, lihat Mengaktifkan change data capture (CDC) menggunakan replikasi logis.
Bekerja dengan database PostgreSQL AWS-managed sebagai sumber DMS
Anda dapat menggunakan instans PostgreSQL DB AWS-managed sebagai sumber untuk. AWS DMS Anda dapat melakukan tugas beban penuh dan tugas change data capture (CDC) dengan menggunakan sumber PostgreSQL terkelola AWS.
Prasyarat untuk menggunakan database AWS PostgreSQL -managed sebagai sumber DMS
Sebelum memigrasikan data dari database sumber AWS PostgreSQL -managed, lakukan hal berikut:
-
Sebaiknya gunakan akun AWS pengguna dengan izin minimum yang diperlukan untuk instans PostgreSQL DB sebagai akun pengguna untuk titik akhir sumber PostgreSQL untuk. AWS DMS Menggunakan akun master tidak disarankan. Akun harus memiliki
rds_superuser
peran danrds_replication
peran. Peranrds_replication
memberikan izin untuk mengelola slot logis dan mengalirkan data menggunakan slot logis.Pastikan untuk membuat beberapa objek dari akun pengguna master untuk akun yang Anda gunakan. Untuk informasi tentang pembuatan objek ini, lihat Memigrasikan basis data Amazon RDS for PostgreSQL tanpa menggunakan akun pengguna utama.
-
Jika basis data sumber Anda dalam virtual private cloud (VPC), pilih grup keamanan VPC yang menyediakan akses ke instans DB di mana basis data berada. Hal ini diperlukan untuk instans replikasi DMS untuk menghubungkan berhasil ke instans DB sumber. Ketika instans replikasi basis data dan DMS dalam VPC yang sama, tambahkan grup keamanan yang sesuai untuk aturan inbound-nya sendiri.
catatan
Beberapa AWS DMS transaksi menganggur selama beberapa waktu sebelum mesin DMS menggunakannya lagi. Dengan menggunakan parameter idle_in_transaction_session_timeout
di PostgreSQL versi 9.6 dan yang lebih tinggi, Anda dapat menyebabkan transaksi idle habis dan gagal. Jangan mengakhiri transaksi yang diam saat Anda menggunakan AWS DMS.
Mengaktifkan CDC dengan instans PostgreSQL DB AWS-managed dengan AWS DMS
AWS DMS mendukung CDC pada database Amazon RDS PostgreSQL ketika instans DB dikonfigurasi untuk menggunakan replikasi logis. Tabel berikut merangkum kompatibilitas replikasi logis dari setiap versi PostgreSQL AWS-managed.
Anda tidak dapat menggunakan RDS PostgreSQL untuk membaca replika untuk CDC (replikasi yang sedang berlangsung).
Versi PostgreSQL |
AWS DMS dukungan beban penuh |
AWS DMS Dukungan CDC |
---|---|---|
Aurora PostgreSQL versi 2.1 ini kompatibel dengan PostgreSQL 10.5 (atau versi di bawahnya). |
Ya |
Tidak |
Aurora PostgreSQL versi 2.2 dengan kompatibilitas PostgreSQL 10.6 (atau lebih tinggi) |
Ya |
Ya |
RDS untuk PostgreSQL dengan kompatibilitas PostgreSQL 10.21 (atau lebih tinggi) |
Ya |
Ya |
Mengaktifkan replikasi logis untuk instans DB RDS PostgreSQL
-
Gunakan akun pengguna AWS master untuk instance PostgreSQL DB sebagai akun pengguna untuk titik akhir sumber PostgreSQL. Akun pengguna utama memiliki peran yang diperlukan yang memungkinkan untuk mengatur CDC.
Jika Anda menggunakan akun selain akun pengguna utama, pastikan untuk membuat beberapa objek dari akun master untuk akun yang Anda gunakan. Untuk informasi selengkapnya, lihat Memigrasikan basis data Amazon RDS for PostgreSQL tanpa menggunakan akun pengguna utama.
-
Atur parameter
rds.logical_replication
dalam grup parameter DB KLASTER Anda menjadi 1. Parameter statis memerlukan reboot dari instans DB agar menjadi berpengaruh. Sebagai bagian dari penerapan parameter ini, AWS DMS menetapkan parameterwal_level
,max_wal_senders
,max_replication_slots
, danmax_connections
. Perubahan parameter ini dapat meningkatkan generasi write ahead log (WAL), jadi aturrds.logical_replication
saja ketika Anda menggunakan slot replikasi logis. -
Parameter
wal_sender_timeout
mengakhiri sambungan replikasi yang tidak aktif lebih lama dari jumlah milidetik tertentu. Default untuk database PostgreSQL AWS-managed adalah 30000 milidetik (30 detik). Menyetel nilai ke 0 (nol) menonaktifkan mekanisme batas waktu, dan merupakan pengaturan yang valid untuk DMS.Saat menyetel
wal_sender_timeout
ke nilai bukan nol, tugas DMS dengan CDC membutuhkan minimal 10.000 milidetik (10 detik), dan gagal jika nilainya antara 0 dan 10000. Jaga nilai kurang dari 5 menit untuk menghindari penundaan selama failover multi-AZ dari instance replikasi DMS. -
Pastikan nilai
max_worker_processes
parameter dalam Grup Parameter Cluster DB Anda sama dengan, atau lebih tinggi dari total nilai gabunganmax_logical_replication_workers
,autovacuum_max_workers
, danmax_parallel_workers
. Sejumlah besar proses pekerja latar belakang dapat memengaruhi beban kerja aplikasi pada instance kecil. Jadi, pantau kinerja database Anda jika Anda menetapkanmax_worker_processes
lebih tinggi dari nilai default. -
Saat menggunakan Aurora PostgreSQL sebagai sumber dengan CDC, atur ke.
synchronous_commit
ON
Memigrasikan basis data Amazon RDS for PostgreSQL tanpa menggunakan akun pengguna utama
Dalam beberapa kasus, Anda mungkin tidak menggunakan akun pengguna utama untuk instans DB Amazon RDS PostgreSQL yang Anda gunakan sebagai sumber. Dalam kasus ini, Anda membuat beberapa objek untuk menangkap peristiwa data definition language (DDL). Anda membuat objek ini di akun selain akun utama kemudian membuat pemicu di akun pengguna utama.
catatan
Jika Anda mengatur pengaturan CaptureDdls
titik akhir ke false
titik akhir sumber, Anda tidak perlu membuat tabel berikut dan memicu pada database sumber.
Gunakan prosedur berikut untuk membuat objek-objek ini.
Membuat objek
-
Pilih skema di tempat objek akan dibuat. Skema default adalah
public
. Pastikan bahwa skema ada dan dapat diakses oleh akun
.OtherThanMaster
-
Masuk ke instans DB PostgreSQL menggunakan akun pengguna selain akun master, berikut akun
.OtherThanMaster
-
Buat tabel
awsdms_ddl_audit
dengan menjalankan perintah berikut, mengganti
dalam kode berikut dengan nama skema untuk yang digunakan.objects_schema
CREATE TABLE
objects_schema
.awsdms_ddl_audit ( c_key bigserial primary key, c_time timestamp, -- Informational c_user varchar(64), -- Informational: current_user c_txn varchar(16), -- Informational: current transaction c_tag varchar(24), -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE' c_oid integer, -- For future use - TG_OBJECTID c_name varchar(64), -- For future use - TG_OBJECTNAME c_schema varchar(64), -- For future use - TG_SCHEMANAME. For now - holds current_schema c_ddlqry text -- The DDL query associated with the current DDL event ); -
Buat fungsi
awsdms_intercept_ddl
dengan menjalankan perintah berikut, mengganti
dalam kode berikut dengan nama skema untuk yang digunakan.objects_schema
CREATE OR REPLACE FUNCTION
objects_schema
.awsdms_intercept_ddl() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ declare _qry text; BEGIN if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then SELECT current_query() into _qry; insert intoobjects_schema
.awsdms_ddl_audit values ( default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry ); delete fromobjects_schema
.awsdms_ddl_audit; end if; END; $$; -
Keluar dari akun
dan masuk dengan akun yang memiliki peranOtherThanMaster
rds_superuser
yang ditentukan akun itu. -
Buat pemicu peristiwab
awsdms_intercept_ddl
dengan menjalankan perintah berikut.CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE
objects_schema
.awsdms_intercept_ddl(); -
Pastikan bahwa semua pengguna dan peran yang mengakses peristiwa ini memiliki izin DDL yang diperlukan. Sebagai contoh:
grant all on public.awsdms_ddl_audit to public; grant all on public.awsdms_ddl_audit_c_key_seq to public;
Ketika Anda telah menyelesaikan prosedur sebelumnya, Anda dapat membuat titik akhir sumber AWS DMS
menggunakan akun
.OtherThanMaster
catatan
Peristiwa ini dipicu oleh pernyataan CREATE TABLE
, ALTER
TABLE
, dan DROP TABLE
.
Mengaktifkan change data capture (CDC) menggunakan replikasi logis
Anda dapat menggunakan fitur replikasi logis asli PostgreSQL untuk mengaktifkan change data capture (CDC) selama migrasi basis data untuk sumber PostgreSQL. Anda dapat menggunakan fitur ini dengan PostgreSQL yang dikelola sendiri dan juga instans Amazon RDS for PostgreSQL SQL DB. Pendekatan ini mengurangi downtime dan membantu memastikan bahwa basis data target sinkron dengan basis data PostgreSQL sumber.
AWS DMS mendukung CDC untuk tabel PostgreSQL dengan kunci utama. Jika tabel tidak memiliki kunci primer, write ahead log (WAL) tidak mencakup gambar sebelum baris basis data. Dalam kasus ini, DMS tidak dapat memperbarui tabel. Di sini, Anda dapat menggunakan pengaturan konfigurasi tambahan dan menggunakan identitas replika tabel sebagai solusi. Namun, pendekatan ini dapat menghasilkan log tambahan. Kami merekomendasikan agar Anda menggunakan identitas replika tabel sebagai solusi hanya setelah pengujian yang cermat. Untuk informasi selengkapnya, lihat Pengaturan konfigurasi tambahan ketika menggunakan basis data PostgreSQL sebagai sumber DMS.
catatan
REPLICA IDENTITY FULL didukung dengan plugin decoding logis, tetapi tidak didukung dengan plugin pglogical. Untuk informasi lebih lanjut, lihat dokumentasi pglogical
Untuk tugas beban penuh dan hanya CDC dan CDC, AWS DMS gunakan slot replikasi logis untuk menyimpan log WAL untuk replikasi hingga log diterjemahkan. Pada saat mengulang kembali (bukan saat melanjutkan) untuk tugas beban penuh dan CDC atau tugas CDC, slot replikasi akan diciptakan kembali.
catatan
Untuk decoding logis, DMS menggunakan test_decoding atau pglogical plugin. Jika plugin pglogical tersedia pada basis data PostgreSQL sumber, DMS menciptakan slot replikasi menggunakan pglogical, jika tidak plugin test_decoding digunakan. Untuk informasi selengkapnya tentang plugin test_decoding, lihat Dokumentasi PostgreSQL.
Jika parameter database max_slot_wal_keep_size
diatur ke nilai non default, dan slot replikasi berada di belakang LSN saat ini lebih dari ukuran ini, tugas DMS gagal karena penghapusan file WAL yang diperlukan. restart_lsn
Mengonfigurasi plugin pglogical
Diimplementasikan sebagai ekstensi PostgreSQL, plugin pglogical adalah sistem replikasi logis dan model untuk replikasi data selektif. Tabel berikut mengidentifikasi versi basis data PostgreSQL sumber yang mendukung plugin pglogical.
Sumber PostgreSQL |
Mendukung pglogical |
---|---|
PostgreSQL 9.4 atau versi yang lebih tinggi yang dikelola sendiri |
Ya |
Amazon RDS PostgreSQL 9.5 atau versi yang lebih rendah |
Tidak |
Amazon RDS PostgreSQL 9.6 atau versi yang lebih tinggi |
Ya |
Aurora PostgreSQL 1.x sampai 2.5.x |
Tidak |
Aurora PostgreSQL 2.6.x atau versi yang lebih tinggi |
Ya |
Aurora PostgreSQL 3.3.x atau versi yang lebih tinggi |
Ya |
Sebelum mengonfigurasi pglogical untuk digunakan dengan AWS DMS, pertama-tama aktifkan replikasi logis untuk pengambilan data perubahan (CDC) pada database sumber PostgreSQL Anda.
-
Untuk informasi tentang pengaktifan replikasi logis untuk CDC pada basis data sumber PostgreSQLyang dikelola sendiri, lihat Mengaktifkan CDC menggunakan database PostgreSQL yang dikelola sendiri sebagai sumber AWS DMS
-
Untuk informasi tentang pengaktifan replikasi logis untuk CDC pada basis data sumber PostgreSQL terkelola AWS, lihat Mengaktifkan CDC dengan instans PostgreSQL DB AWS-managed dengan AWS DMS.
Setelah replikasi logis diaktifkan pada basis data sumber PostgreSQL Anda, gunakan langkah-langkah berikut untuk mengonfigurasi pglogical untuk digunakan dengan DMS.
Untuk menggunakan plugin pglogical untuk replikasi logis pada database sumber PostgreSQL dengan AWS DMS
-
Buat ekstensi pglogical pada basis data PostgreSQL sumber Anda:
-
Atur parameter yang benar:
-
Untuk basis data PostgreSQL yang dikelola sendiri, atur parameter basis data
shared_preload_libraries= 'pglogical'
. -
Untuk basis data PostgreSQL pada Amazon RDS dan Amazon Aurora Edisi Kompatibel PostgreSQL, atur parameter
shared_preload_libraries
menjadipglogical
dalam grup parameter RDS yang sama.
-
-
Mulai ulang basis data sumber PostgreSQL Anda.
-
Pada basis data PostgreSQL, jalankan perintah,
create extension pglogical;
-
-
Jalankan perintah berikut untuk melakukan verifikasi bahwa pglogical berhasil diinstal:
select * FROM pg_catalog.pg_extension
Anda sekarang dapat membuat AWS DMS tugas yang melakukan perubahan pengambilan data untuk titik akhir database sumber PostgreSQL Anda.
catatan
Jika Anda tidak mengaktifkan pglogical pada basis data sumber PostgreSQL Anda, AWS DMS menggunakan plugin test_decoding
secara default. Ketika pglogical diaktifkan untuk decoding logis, AWS DMS gunakan pglogical secara default. Tapi Anda dapat mengatur atribut sambungan tambahan, PluginName
untuk menggunakan plugin test_decoding
sebagai gantinya.
Menggunakan titik awal CDC asli untuk mengatur beban CDC dari sumber PostgreSQL
Untuk mengaktifkan titik awal CDC asli dengan PostgreSQL sebagai sumber, atur atribut sambungan tambahan slotName
menjadi nama slot replikasi logis yang ada ketika Anda membuat titik akhir. Slot replikasi logis ini menyimpan perubahan yang sedang berlangsung dari waktu penciptaan titik akhir, sehingga mendukung replikasi dari periode waktu sebelumnya.
PostgreSQL menulis perubahan basis data di file WAL yang dibuang hanya setelah AWS DMS berhasil membaca perubahan dari slot replikasi logis. Menggunakan slot replikasi logis dapat melindungi perubahan yang dicatat dari penghapusan sebelum slot dikonsumsi oleh mesin replikasi.
Namun, tergantung pada tingkat perubahan dan konsumsi, perubahan yang disimpan di slot replikasi logis dapat menyebabkan peningkatan penggunaan disk. Kami merekomendasikan agar Anda mengatur ruang penggunaan alarm dalam instans PostgreSQL sumber ketika Anda menggunakan slot replikasi logis. Untuk informasi lebih lanjut tentang pengaturan atribut sambungan tambahan slotName
, lihat Pengaturan titik akhir dan Atribut Koneksi Ekstra (ECAs) saat menggunakan PostgreSQL sebagai sumber DMS.
Prosedur berikut melalui pendekatan ini secara lebih rinci.
Menggunakan titik awal CDC asli untuk mengatur beban CDC dari titik akhir sumber PostgreSQL
-
Identifikasi slot replikasi logis yang digunakan oleh tugas replikasi sebelumnya (tugas induk) yang ingin Anda gunakan sebagai titik awal. Kemudian lakukan kueri tampilan
pg_replication_slots
pada basis data sumber Anda untuk memastikan bahwa slot ini tidak memiliki sambungan aktif. Jika ya, selesaikan dan tutup sebelum melanjutkan.Untuk langkah-langkah berikut, anggaplah bahwa slot replikasi logis Anda
abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef
. -
Buat titik akhir sumber baru yang mencakup pengaturan atribut sambungan tambahan berikut.
slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;
-
Buat tugas baru khusus CDC menggunakan konsol, AWS CLI atau AWS DMS API. Misalnya, dengan menggunakan CLI Anda dapat menjalankan perintah
create-replication-task
berikut.aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test --source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 --target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 --replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE --migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" --replication-task-settings "file://task-pg.json"
Dalam perintah sebelumnya, opsi berikut ditetapkan:
-
Opsi
source-endpoint-arn
diatur menjadi nilai baru yang Anda buat di langkah 2. -
Opsi
replication-instance-arn
diatur menjadi nilai yang sama seperti untuk tugas induk dari langkah 1. -
Opsi
table-mappings
danreplication-task-settings
ditetapkan menjadi nilai yang sama seperti untuk tugas induk dari langkah 1. -
Opsi
cdc-start-position
diatur menjadi nilai posisi awal. Untuk menemukan posisi awal ini, lakukan kueri tampilanpg_replication_slots
pada basis data sumber Anda atau lihat detail konsol untuk tugas induk di langkah 1. Untuk informasi selengkapnya, lihat Menentukan titik awal CDC asli.
Untuk mengaktifkan mode mulai CDC khusus saat membuat tugas khusus CDC baru menggunakan AWS DMS konsol, lakukan hal berikut:
Di bagian Pengaturan tugas, untuk mode mulai CDC untuk transaksi sumber, pilih Aktifkan mode mulai CDC khusus.
Untuk titik awal CDC khusus untuk transaksi sumber, pilih Tentukan nomor urutan log. Tentukan nomor perubahan sistem atau pilih Tentukan pos pemeriksaan pemulihan, dan berikan pos pemeriksaan Pemulihan.
Saat tugas CDC ini berjalan, AWS DMS memunculkan kesalahan jika slot replikasi logis yang ditentukan tidak ada. Hal ini juga menimbulkan kesalahan jika tugas tidak dibuat dengan pengaturan yang valid untuk
cdc-start-position
. -
Ketika menggunakan titik awal CDC asli dengan plugin pglogical dan Anda ingin menggunakan slot replikasi baru, selesaikan langkah-langkah pengaturan berikut sebelum membuat tugas CDC.
Menggunakan slot replikasi baru yang sebelumnya tidak dibuat sebagai bagian dari tugas DMS lain
-
Buat slot replikasi, seperti yang ditunjukkan berikut:
SELECT * FROM pg_create_logical_replication_slot('
replication_slot_name
', 'pglogical'); -
Setelah database membuat slot replikasi, dapatkan dan catat nilai restart_lsn dan confirmed_flush_lsn untuk slot:
select * from pg_replication_slots where slot_name like 'replication_slot_name';
Perhatikan bahwa posisi Mulai CDC Asli untuk tugas CDC yang dibuat setelah slot replikasi tidak boleh lebih tua dari nilai confirmed_flush_lsn.
Untuk informasi tentang nilai restart_lsn dan confirmed_flush_lsn, lihat pg_replication_slots
-
Buat node pglogical.
SELECT pglogical.create_node(node_name := '
node_name
', dsn := 'your_dsn_name
'); -
Buat dua set replikasi menggunakan
pglogical.create_replication_set
fungsi. Set replikasi pertama melacak pembaruan dan penghapusan untuk tabel yang memiliki kunci utama. Set replikasi kedua hanya menyisipkan, dan memiliki nama yang sama dengan set replikasi pertama, dengan awalan tambahan 'i'.SELECT pglogical.create_replication_set('
replication_slot_name
', false, true, true, false); SELECT pglogical.create_replication_set('ireplication_slot_name
', true, false, false, true); -
Tambahkan tabel pada set replikasi.
SELECT pglogical.replication_set_add_table('
replication_slot_name
', 'schemaname.tablename', true); SELECT pglogical.replication_set_add_table('ireplication_slot_name
', 'schemaname.tablename', true); -
Atur atribut sambungan tambahan (ECA) berikut ketika Anda membuat titik akhir sumber Anda.
PluginName=PGLOGICAL;slotName=
slot_name
;
Anda sekarang dapat membuat tugas CDC saja dengan titik awal asli PostgreSQL menggunakan slot replikasi baru. Untuk informasi lebih lanjut tentang plugin pglogical, lihat dokumentasi pglogical
Migrasi dari PostgreSQL ke PostgreSQL menggunakan AWS DMS
Ketika Anda bermigrasi dari mesin database selain PostgreSQL ke database PostgreSQL, hampir selalu merupakan alat migrasi terbaik untuk digunakan AWS DMS . Tapi ketika Anda bermigrasi dari basis data PostgreSQL ke basis data PostgreSQL, alat PostgreSQL bisa lebih efektif.
Menggunakan alat asli PostgreSQL untuk memigrasi data
Kami menyarankan Anda untuk menggunakan alat migrasi basis data seperti pg_dump
dalam kondisi berikut:
-
Anda memiliki migrasi yang homogen, yaitu Anda bermigrasi dari basis data PostgreSQL sumber ke basis data PostgreSQL target.
-
Anda memigrasi seluruh basis data.
-
Alat asli mengizinkan Anda untuk memigrasi data Anda dengan waktu downtime minimal.
Utilitas pg_dump menggunakan perintah COPY untuk membuat skema dan data dump dari basis data PostgreSQL. Skrip dump yang dibuat oleh pg_dump memuat data ke dalam basis data dengan nama yang sama dan membuat ulang tabel, indeks, dan kunci asing. Untuk memulihkan data ke basis data dengan nama yang berbeda, gunakan perintah pg_restore
dan parameter -d
.
Jika Anda memigrasikan data dari database sumber PostgreSQL yang berjalan ke target Amazon EC2 RDS for PostgreSQL, Anda dapat menggunakan plugin pglogical.
Untuk informasi lebih lanjut tentang impor basis data PostgreSQL ke dalam Amazon RDS for PostgreSQL atau Amazon Aurora Edisi Kompatibel PostgreSQL, lihat https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html.
Menggunakan DMS untuk memigrasi data dari PostgreSQL ke PostgreSQL
AWS DMS dapat memigrasikan data, misalnya, dari database PostgreSQL sumber yang ada di lokasi ke target Amazon RDS for PostgreSQL atau instance PostgreSQL Aurora. Jenis data PostgreSQL inti atau basic paling sering bermigrasi dengan berhasil.
catatan
Ketika mereplikasi tabel dipartisi dari sumber PostgreSQL ke target PostgreSQL, Anda tidak perlu menyebutkan tabel induk sebagai bagian dari kriteria seleksi dalam tugas DMS. Menyebutkan tabel induk menyebabkan data diduplikasi dalam tabel anak pada target, dapat menyebabkan pelanggaran PK. Dengan memilih tabel anak saja dalam kriteria pemilihan pemetaan tabel, tabel induk secara otomatis diisi.
Tipe data yang didukung pada database sumber tetapi tidak didukung pada target mungkin tidak berhasil bermigrasi. AWS DMS mengalirkan beberapa tipe data sebagai string jika tipe data tidak diketahui. Beberapa jenis data, seperti XML dan JSON, dapat berhasil bermigrasi sebagai file kecil tetapi dapat gagal jika mereka merupakan dokumen besar.
Saat melakukan migrasi jenis data, perhatikan hal-hal berikut:
-
Dalam beberapa kasus, jenis data PostgreSQL NUMERIC(p,s) tidak menentukan presisi dan skala apa pun. Untuk DMS versi 3.4.2 dan versi sebelumnya, DMS menggunakan presisi 28 dan skala 6 secara default, NUMERIC (28,6). Misalnya, nilai 0.611111104488373 dari sumber dikonversi menjadi 0.611111 pada target PostgreSQL.
-
Tabel dengan jenis data ARRAY harus memiliki kunci primer. Tabel dengan jenis data ARRAY yang kekurangan kunci primer akan ditangguhkan selama beban penuh.
Tabel berikut menunjukkan sumber jenis data PostgreSQL dan apakah mereka dapat berhasil dimigrasi.
Jenis data | Berhasil bermigrasi | Bermigrasi sebagian | Tidak bermigrasi | Komentar |
---|---|---|---|---|
INTEGER | X | |||
SMALLINT | X | |||
BIGINT | X | |||
NUMERIC/DECIMAL(p,s) | X | Di mana 0<p<39 dan 0<s | ||
NUMERIC/DECIMAL | X | Di mana p>38 atau p=s=0 | ||
REAL | X | |||
DOUBLE | X | |||
SMALLSERIAL | X | |||
SERIAL | X | |||
BIGSERIAL | X | |||
MONEY | X | |||
CHAR | X | Tanpa presisi tertentu | ||
CHAR(N) | X | |||
VARCHAR | X | Tanpa presisi tertentu | ||
VARCHAR(N) | X | |||
TEXT | X | |||
BYTEA | X | |||
TIMESTAMP | X | Nilai tak terhingga positif dan negatif dipotong menjadi '9999-12-31 23:59:59 'dan '4713-01-01 00:00:00 BC' masing-masing. | ||
TIMESTAMP WITH TIME ZONE | X | |||
DATE | X | |||
TIME | X | |||
TIME WITH TIME ZONE | X | |||
INTERVAL | X | |||
BOOLEAN | X | |||
ENUM | X | |||
CIDR | X | |||
INET | X | |||
MACADDR | X | |||
TSVECTOR | X | |||
TSQUERY | X | |||
XML | X | |||
POINT | X | Jenis data spasial PostGIS | ||
LINE | X | |||
LSEG | X | |||
BOX | X | |||
PATH | X | |||
POLYGON | X | Jenis data spasial PostGIS | ||
CIRCLE | X | |||
JSON | X | |||
ARRAY | X | Memerlukan Kunci Primer | ||
COMPOSITE | X | |||
RANGE | X | |||
LINESTRING | X | Jenis data spasial PostGIS | ||
MULTIPOINT | X | Jenis data spasial PostGIS | ||
MULTILINESTRING | X | Jenis data spasial PostGIS | ||
MULTIPOLYGON | X | Jenis data spasial PostGIS | ||
GEOMETRYCOLLECTION | X | Jenis data spasial PostGIS |
Memigrasikan jenis data spasial PostGIS
Data spasial mengidentifikasi informasi geometri dari suatu objek atau lokasi di ruang. Basis data relasional objek PostgreSQL mendukung jenis data spasial PostGIS.
Sebelum memigrasi objek data spasial PostgreSQL, pastikan plugin PostGIS diaktifkan pada tingkat global. Melakukan hal ini memastikan bahwa AWS DMS menciptakan kolom data spasial sumber yang tepat untuk instance DB target PostgreSQL.
Untuk PostgreSQL ke PostgreSQL AWS DMS migrasi homogen PostgreSQL, mendukung migrasi tipe dan subtipe objek data geometris dan geografis PostGIS (koordinat geodetik) seperti berikut ini:
-
POINT
-
LINESTRING
-
POLYGON
-
MULTIPOINT
-
MULTILINESTRING
-
MULTIPOLYGON
-
GEOMETRYCOLLECTION
Bermigrasi dari Babelfish untuk Amazon Aurora PostgreSQL menggunakan AWS DMS
Anda dapat memigrasikan tabel sumber Babelfish untuk Aurora PostgreSQL ke titik akhir target yang didukung. AWS DMS
Saat membuat titik akhir AWS DMS sumber menggunakan konsol DMS, API, atau perintah CLI, Anda menyetel sumbernya ke Amazon Aurora PostgreSQL, dan nama database ke. babelfish_db
Di bagian Pengaturan Endpoint, pastikan bahwa DatabaseModediatur ke Babelfish, dan BabelfishDatabaseNamediatur ke nama sumber database Babelfish T-SQL. Alih-alih menggunakan port TCP Babelfish1433
, gunakan port Aurora PostgreSQL TCP. 5432
Anda harus membuat tabel sebelum memigrasi data untuk memastikan bahwa DMS menggunakan tipe data dan metadata tabel yang benar. Jika Anda tidak membuat tabel pada target sebelum menjalankan migrasi, DMS dapat membuat tabel dengan tipe data dan izin yang salah.
Menambahkan aturan transformasi ke tugas migrasi
Saat membuat tugas migrasi untuk sumber Babelfish, Anda perlu menyertakan aturan transformasi yang memastikan bahwa DMS menggunakan tabel target yang telah dibuat sebelumnya.
Jika Anda menetapkan mode migrasi multi-database saat menentukan Babelfish untuk klaster PostgreSQL, tambahkan aturan transformasi yang mengganti nama skema ke skema T-SQL. Misalnya, jika nama skema T-SQL adalahdbo
, dan nama skema Babelfish untuk PostgreSQL Anda, ganti nama skema menjadi menggunakan aturan transformasi. mydb_dbo
dbo
Untuk menemukan nama skema PostgreSQL, lihat Arsitektur Babelfish di Panduan Pengguna Amazon Aurora.
Jika Anda menggunakan mode database tunggal, Anda tidak perlu menggunakan aturan transformasi untuk mengganti nama skema database. Nama skema PostgreSQL memiliki pemetaan ke nama skema one-to-one dalam database T-SQL.
Contoh aturan transformasi berikut menunjukkan cara mengganti nama nama skema dari mydb_dbo
belakang ke: dbo
{
"rules": [
{
"rule-type": "transformation",
"rule-id": "566251737",
"rule-name": "566251737",
"rule-target": "schema",
"object-locator": {
"schema-name": "mydb_dbo"
},
"rule-action": "rename",
"value": "dbo",
"old-value": null
},
{
"rule-type": "selection",
"rule-id": "566111704",
"rule-name": "566111704",
"object-locator": {
"schema-name": "mydb_dbo",
"table-name": "%"
},
"rule-action": "include",
"filters": []
}
]
}
Batasan untuk menggunakan titik akhir sumber PostgreSQL dengan tabel Babelfish
Batasan berikut berlaku saat menggunakan titik akhir sumber PostgreSQL dengan tabel Babelfish:
DMS hanya mendukung migrasi dari Babelfish versi 16.2/15.6 dan yang lebih baru, dan DMS versi 3.5.3 dan yang lebih baru.
DMS tidak mereplikasi perubahan definisi tabel Babelfish ke titik akhir target. Solusi untuk batasan ini adalah dengan terlebih dahulu menerapkan perubahan definisi tabel pada target, dan kemudian mengubah definisi tabel pada sumber Babelfish.
Saat Anda membuat tabel Babelfish dengan tipe data BYTEA, DMS mengonversinya menjadi tipe
varbinary(max)
data saat bermigrasi ke SQL Server sebagai target.DMS tidak mendukung mode LOB Penuh untuk tipe data biner. Gunakan mode LOB terbatas untuk tipe data biner sebagai gantinya.
DMS tidak mendukung validasi data untuk Babelfish sebagai sumber.
Untuk pengaturan tugas mode persiapan tabel Target, gunakan hanya mode Do nothing atau Truncate. Jangan gunakan tabel Drop pada mode target. Saat menggunakan tabel Drop pada target, DMS dapat membuat tabel dengan tipe data yang salah.
Saat menggunakan replikasi berkelanjutan (CDC atau Full load dan CDC), atur atribut koneksi
PluginName
tambahan (ECA) ke.TEST_DECODING
-
DMS tidak mendukung replikasi (CDC atau Full load dan CDC) dari tabel yang dipartisi untuk Babelfish sebagai sumber.
Menghapus AWS DMS artefak dari database sumber PostgreSQL
Untuk menangkap peristiwa DDL, AWS DMS membuat berbagai artefak dalam database PostgreSQL saat tugas migrasi dimulai. Saat tugas selesai, Anda mungkin ingin menghapus artefak ini.
Untuk menghapus artefak, keluarkan pernyataan berikut (dalam urutan saat muncul), di mana {AmazonRDSMigration}
adalah skema di mana artefak dibuat. Menjatuhkan skema harus dilakukan dengan sangat hati-hati. Jangan pernah menjatuhkan skema operasional, apalagi skema publik.
drop event trigger awsdms_intercept_ddl;
Pemicu peristiwa bukan milik skema tertentu.
drop function {AmazonRDSMigration}.awsdms_intercept_ddl()
drop table {AmazonRDSMigration}.awsdms_ddl_audit
drop schema {AmazonRDSMigration}
Pengaturan konfigurasi tambahan ketika menggunakan basis data PostgreSQL sebagai sumber DMS
Anda dapat menambahkan pengaturan konfigurasi tambahan ketika memigrasi data dari basis data PostgreSQL dengan dua cara:
-
Anda dapat menambahkan nilai ke atribut sambungan tambahan untuk menangkap peristiwa DDL dan menentukan skema di mana artefak basis data DL operasional dibuat. Untuk informasi selengkapnya, lihat Pengaturan titik akhir dan Atribut Koneksi Ekstra (ECAs) saat menggunakan PostgreSQL sebagai sumber DMS.
-
Anda dapat mengganti parameter string sambungan. Pilih opsi ini untuk melakukan salah satu dari berikut:
-
Tentukan AWS DMS parameter internal. Parameter tersebut jarang diperlukan sehingga tidak tampak di antarmuka pengguna.
-
Tentukan nilai pass-through (passthru) untuk klien database tertentu. AWS DMS termasuk parameter pass-through dalam sengatan koneksi yang diteruskan ke klien database.
-
-
Dengan menggunakan parameter tingkat tabel di
REPLICA IDENTITY
PostgreSQL versi 9.4 dan yang lebih tinggi, Anda dapat mengontrol informasi yang ditulis ke log write-ahead (). WALs Secara khusus, ia melakukannya untuk WALs mengidentifikasi baris yang diperbarui atau dihapus.REPLICA IDENTITY FULL
mencatat nilai lama dari semua kolom di baris. GunakanREPLICA IDENTITY FULL
dengan hati-hati untuk setiap tabel karenaFULL
menghasilkan jumlah tambahan WALs yang mungkin tidak diperlukan. Untuk informasi lebih lanjut, lihat ALTER TABLE-REPLICAIDENTITY
Menggunakan pengaturan titik akhir MapBooleanAsBoolean PostgreSQL
Anda dapat menggunakan pengaturan titik akhir PostgreSQL untuk memetakan boolean sebagai boolean dari sumber PostgreSQL Anda ke target Amazon Redshift. Secara default, tipe BOOLEAN dimigrasikan sebagai varchar (5). Anda dapat menentukan MapBooleanAsBoolean
untuk membiarkan PostgreSQL memigrasikan jenis boolean sebagai boolean seperti yang ditunjukkan pada contoh berikut.
--postgre-sql-settings '{"MapBooleanAsBoolean": true}'
Perhatikan bahwa Anda harus mengatur pengaturan ini pada titik akhir sumber dan target agar dapat diterapkan.
Karena MySQL tidak memiliki tipe BOOLEAN, gunakan aturan transformasi daripada pengaturan ini saat memigrasi data BOOLEAN ke MySQL.
Pengaturan titik akhir dan Atribut Koneksi Ekstra (ECAs) saat menggunakan PostgreSQL sebagai sumber DMS
Anda dapat menggunakan pengaturan titik akhir dan atribut koneksi tambahan (ECAs) untuk mengonfigurasi basis data sumber PostgreSQL Anda. Anda menentukan pengaturan titik akhir saat membuat titik akhir sumber menggunakan AWS DMS konsol, atau dengan menggunakan create-endpoint
perintah di AWS CLI, dengan sintaks --postgre-sql-settings '{"
JSON.EndpointSetting"
:
"value"
, ...
}'
Tabel berikut menunjukkan pengaturan endpoint dan ECAs yang dapat Anda gunakan dengan PostgreSQL sebagai sumber.
Nama atribut | Deskripsi |
---|---|
|
Untuk menangkap peristiwa DDL, AWS DMS membuat berbagai artefak dalam database PostgreSQL saat tugas dimulai. Anda nantinya dapat menghapus artefak ini seperti yang dijelaskan di Menghapus AWS DMS artefak dari database sumber PostgreSQL. Jika nilai ini disetel ke false, Anda tidak perlu membuat tabel atau pemicu pada database sumber. Acara DDL yang dikeluarkan ditangkap. Nilai default: Nilai yang benar: benar/salah Contoh: |
|
Digunakan untuk mengontrol bagaimana transaksi monolitik dengan duplikat Log Sequence Numbers (LSNs) direplikasi. Ketika parameter ini Nilai default: Nilai yang benar: salah/benar Contoh: |
|
Menetapkan skema di mana artefak basis data DL operasional dibuat. Nilai default: publik Nilai yang benar: String Contoh: |
|
Menonaktifkan filter sumber Unicode dengan PostgreSQL, untuk nilai yang diteruskan ke filter aturan Selection pada nilai kolom Source Endpoint. Secara default DMS melakukan perbandingan filter sumber menggunakan string Unicode yang dapat menyebabkan pencarian mengabaikan indeks di kolom teks dan memperlambat migrasi. Dukungan Unicode seharusnya hanya dinonaktifkan ketika menggunakan filter aturan pemilihan pada kolom teks dalam database Sumber yang diindeks. Nilai default: SALAH Nilai yang benar: benar/salah Contoh: |
|
Menetapkan pernyataan timeout klien untuk instans PostgreSQL, dalam hitungan detik. Nilai default adalah 60 detik. Contoh: |
|
Ketika diatur menjadi Jika tugas diatur ke modus LOB terbatas dan opsi ini diatur menjadi benar, tugas gagal alih-alih memotong data LOB. Nilai default: salah Nilai yang benar: Boolean Contoh: |
|
Atribut koneksi tambahan (ECA) ini menetapkan jumlah baris yang akan diambil kursor selama operasi beban penuh. Bergantung pada sumber daya yang tersedia dalam contoh replikasi, Anda dapat menyesuaikan nilainya lebih tinggi atau lebih rendah. Nilai default: Nilai yang benar: Angka Contoh ECA: |
|
Fitur WAL heartbeat meniru transaksi dummy, sehingga slot replikasi logis diam tidak berpegang pada log WAL lama yang mengakibatkan situasi penyimpanan penuh pada sumber. Heartbeat ini terus membuat Nilai default: Nilai yang benar: benar/salah Contoh: |
|
Menetapkan frekuensi WAL heartbeat (dalam menit). Nilai default: Nilai yang benar: Angka Contoh: |
|
Menetapkan skema di mana artefak heartbeat dibuat. Nilai default: Nilai yang benar: String Contoh: |
|
Secara default, AWS DMS memetakan JSONB ke NCLOB. Anda dapat menentukan Contoh: |
|
Secara default, AWS DMS memetakan VARCHAR ke WSTRING. Anda dapat menentukan
Contoh: |
|
Parameter ini memperlakukan kolom dengan jenis data NUMERIC tak terbatas sebagai STRING agar berhasil bermigrasi tanpa kehilangan presisi dari nilai numerik. Gunakan parameter ini hanya untuk replikasi dari sumber PostgreSQL ke target PostgreSQL, atau basis data dengan kompatibilitas PostgreSQL. Nilai default: Nilai valid: Contoh: Menggunakan parameter ini dapat mengakibatkan beberapa degradasi performa replikasi karena transformasi dari numerik ke string dan kembali ke numerik. Parameter ini didukung untuk digunakan oleh DMS versi 3.4.4 dan versi yang lebih tinggi catatanHanya gunakan Penggunaan titik akhir PostgreSQL sumber membatasi presisi hingga 28 selama CDC. Jangan gunakan |
|
Menentukan plugin yang digunakan untuk membuat slot replikasi. Nilai yang valid: Contoh: |
|
Menetapkan nama slot replikasi logis yang dibuat sebelumnya untuk beban CDC dari instans sumber PostgreSQL. Saat digunakan dengan parameter Untuk informasi selengkapnya tentang pengaturan parameter permintaan Nilai yang benar: String Contoh: |
|
Atribut Koneksi Ekstra (ECA) ini mendefinisikan ukuran maksimum kolom data yang didefinisikan sebagai tipe VarChar tanpa penentu panjang maksimum. Defaultnya adalah 8000 byte. Nilai maksimumnya adalah 10485760 byte. |
Keterbatasan menggunakan basis data PostgreSQL sebagai sumber DMS
Keterbatasan berikut berlaku ketika menggunakan PostgreSQL sebagai sumber untuk AWS DMS:
-
AWS DMS tidak berfungsi dengan Amazon RDS untuk PostgreSQL 10.4 atau Amazon Aurora PostgreSQL 10.4 baik sebagai sumber atau target.
-
Tabel yang ditangkap harus memiliki kunci primer. Jika tabel tidak memiliki kunci utama, AWS DMS abaikan operasi DELETE dan UPDATE record untuk tabel tersebut. Sebagai solusinya, lihat Mengaktifkan pengambilan data perubahan (CDC) menggunakan replikasi logis.
Catatan: Kami tidak menyarankan migrasi tanpa Kunci Primer/Indeks Unik, jika tidak, batasan tambahan berlaku seperti kemampuan penerapan Batch “TIDAK”, kemampuan LOB Penuh, Validasi Data, dan ketidakmampuan untuk mereplikasi ke target Redshift secara efisien.
-
AWS DMS mengabaikan upaya untuk memperbarui segmen kunci primer. Dalam kasus ini, target mengidentifikasi pembaruan sebagai salah satu yang tidak memperbarui baris apapun. Namun, karena hasil memperbarui kunci primer di PostgreSQL tidak dapat diprediksi, tidak ada catatan yang ditulis ke tabel pengecualian.
-
AWS DMS tidak mendukung opsi Start Process Changes from Timestamp run.
-
AWS DMS tidak mereplikasi perubahan yang dihasilkan dari operasi partisi atau subpartisi (
ADD
,DROP
, atauTRUNCATE
). -
Replikasi beberapa tabel dengan nama yang sama di mana setiap nama memiliki kasus yang berbeda (misalnya, tabel1 TABLE1, dan Tabel1) dapat menyebabkan perilaku yang tidak terduga. Karena masalah ini, AWS DMS tidak mendukung jenis replikasi ini.
-
Dalam kebanyakan kasus, AWS DMS mendukung pemrosesan perubahan pernyataan CREATE, ALTER, dan DROP DDL untuk tabel. AWS DMS tidak mendukung pemrosesan perubahan ini jika tabel disimpan dalam fungsi bagian dalam atau blok badan prosedur atau dalam konstruksi bersarang lainnya.
Sebagai contoh, perubahan berikut tidak ditangkap.
CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void LANGUAGE plpgsql AS $$ BEGIN create table attu.distributors1(did serial PRIMARY KEY,name varchar(40) NOT NULL); END; $$;
-
Saat ini, jenis data
boolean
dalam sumber PostgreSQL dimigrasi ke target SQL Server sebagai jejnis databit
dengan nilai-nilai yang tidak konsisten. Sebagai solusinya, pra-buat tabel dengan tipeVARCHAR(1)
data untuk kolom (atau minta AWS DMS membuat tabel). Kemudian buatlah pemrosesan hilir memperlakukan “F” sebagai False dan “T” sebagai True. -
AWS DMS tidak mendukung pemrosesan perubahan operasi TRUNCATE.
-
Jenis data OID LOB tidak bermigrasi ke target.
AWS DMS mendukung tipe data PostGIS hanya untuk migrasi homogen.
-
Jika sumber Anda adalah database PostgreSQL yang ada di lokasi atau di instans EC2 Amazon, pastikan plugin keluaran test_decoding diinstal pada titik akhir sumber Anda. Anda dapat menemukan plugin ini di paket kontrib PostgreSQL. Untuk informasi lebih lanjut tentang plugin test-decoding, lihat Dokumentasi PostgreSQL
. -
AWS DMS tidak mendukung pemrosesan perubahan untuk mengatur dan menghapus nilai default kolom (menggunakan klausa ALTER COLUMN SET DEFAULT pada pernyataan ALTER TABLE).
-
AWS DMS tidak mendukung pemrosesan perubahan untuk mengatur nullabilitas kolom (menggunakan klausa ALTER COLUMN [SET|DROP] NOT NULL pada pernyataan ALTER TABLE).
-
Ketika replikasi logis diaktifkan, jumlah maksimum perubahan yang disimpan dalam memori per transaksi adalah 4 MB. Setelah itu, pengubahan dijatuhkan ke disk. Hasilnya
ReplicationSlotDiskUsage
meningkat, danrestart_lsn
tidak maju sampai transaksi selesai atau berhenti dan rollback selesai. Karena merupakan transaksi yang panjang, itu dapat memakan waktu lama untuk rollback. Jadi, hindari transaksi yang berjalan lama atau banyak sub-transaksi saat replikasi logis diaktifkan. Sebaliknya, pisah transaksi menjadi beberapa transaksi yang lebih kecil.Pada Aurora PostgreSQL versi 13 dan yang lebih baru, Anda dapat menyetel
logical_decoding_work_mem
parameter untuk mengontrol ketika DMS tumpah mengubah data ke disk. Untuk informasi selengkapnya, lihat Menumpahkan file di Aurora PostgreSQL. -
Tabel dengan jenis data ARRAY harus memiliki kunci primer. Tabel dengan jenis data ARRAY yang kekurangan kunci primer akan ditangguhkan selama beban penuh.
-
AWS DMS tidak mendukung replikasi tabel yang dipartisi. Ketika tabel dipartisi terdeteksi, hal berikut terjadi:
-
Titik akhir melaporkan daftar tabel induk dan anak.
-
AWS DMS membuat tabel pada target sebagai tabel biasa dengan properti yang sama dengan tabel yang dipilih.
-
Jika tabel induk dalam basis data sumber memiliki nilai kunci primer yang sama denngan tabel anaknya, kesalahan “duplikat kunci” muncul.
-
-
Untuk mereplikasi tabel dipartisi dari sumber PostgreSQL ke target PostgreSQL, pertama-tama secara manual buatlah tabel induk dan anak pada target. Kemudian tentukan tugas terpisah untuk mereplikasi ke tabel tersebut. Dalam kasus seperti itu, atur konfigurasi tugas Potong sebelum memuat.
-
Jenis data
NUMERIC
PostgreSQL tidak tentu dalam hal ukuran. Saat mentransfer data yang merupakan jenis dataNUMERIC
tetapi tanpa presisi dan skala, DMS menggunakanNUMERIC(28,6)
(presisi 28 dan skala 6) secara default. Sebagai contoh, nilai 0.611111104488373 dari sumber dikonversi menjadi 0.611111 pada target PostgreSQL. -
AWS DMS mendukung Aurora PostgreSQL Serverless V1 sebagai sumber untuk tugas beban penuh saja. AWS DMS mendukung Aurora PostgreSQL Serverless V2 sebagai sumber untuk beban penuh, beban penuh dan CDC, dan tugas khusus CDC.
-
AWS DMS tidak mendukung replikasi tabel dengan indeks unik yang dibuat dengan fungsi coalesce.
-
Jika definisi kunci primer pada sumber dan target tidak cocok, hasil replikasi mungkin tidak dapat diprediksi.
-
Saat menggunakan fitur Parallel Load, segmentasi tabel menurut partisi atau sub-partisi tidak didukung. Untuk informasi selengkapnya tentang Beban Paralel, lihat Menggunakan beban paralel untuk tabel, tampilan, dan koleksi yang dipilih
-
AWS DMS tidak mendukung Kendala yang Ditangguhkan.
-
AWS DMS versi 3.4.7 mendukung PostgreSQL 14.x sebagai sumber dengan keterbatasan ini:
-
AWS DMS tidak mendukung pemrosesan perubahan komit dua fase.
-
AWS DMS tidak mendukung replikasi logis untuk mengalirkan transaksi yang sedang berlangsung lama.
-
-
AWS DMS tidak mendukung CDC untuk Amazon RDS Proxy untuk PostgreSQL sebagai sumber.
-
Saat menggunakan filter sumber yang tidak berisi kolom Kunci Utama,
DELETE
operasi tidak akan ditangkap. -
Jika database sumber Anda juga merupakan target untuk sistem replikasi pihak ketiga lainnya, perubahan DDL mungkin tidak bermigrasi selama CDC. Karena situasi itu dapat mencegah pemicu
awsdms_intercept_ddl
peristiwa menembak. Untuk mengatasi situasi tersebut, ubah pemicu itu pada basis data sumber Anda sebagai berikut:alter event trigger awsdms_intercept_ddl enable always;
-
AWS DMS tidak mendukung CDC untuk cluster database Multi-AZ Amazon RDS untuk PostgreSQL sebagai sumber, karena RDS untuk cluster database PostgreSQL Multi-AZ tidak mendukung replikasi logis.
Jenis data sumber untuk PostgreSQL
Tabel berikut menunjukkan tipe data sumber PostgreSQL yang didukung saat AWS DMS menggunakan dan pemetaan default ke tipe data. AWS DMS
Untuk informasi tentang cara melihat jenis data yang dipetakan dalam target, lihat bagian titik akhir target yang Anda gunakan.
Untuk informasi tambahan tentang tipe AWS DMS data, lihatTipe data untuk AWS Database Migration Service.
Jenis data PostgreSQL |
Jenis data DMS |
---|---|
INTEGER |
INT4 |
SMALLINT |
INT2 |
BIGINT |
INT8 |
NOMERIC (p,s) |
Jika presisi adalah dari 0 sampai 38, maka gunakan NUMERIC. Jika presisi adalah 39 atau lebih besar, maka gunakan STRING. |
DECIMAL(P,S) |
Jika presisi adalah dari 0 sampai 38, maka gunakan NUMERIC. Jika presisi adalah 39 atau lebih besar, maka gunakan STRING. |
REAL |
REAL4 |
DOUBLE |
REAL8 |
SMALLSERIAL |
INT2 |
SERIAL |
INT4 |
BIGSERIAL |
INT8 |
MONEY |
NUMERIC(38,4) Jenis data MONEY dipetakan ke FLOAT di SQL Server. |
CHAR |
WSTRING (1) |
CHAR(N) |
WSTRING (n) |
VARCHAR(N) |
WSTRING (n) |
TEXT |
NCLOB |
CITEXT |
NCLOB |
BYTEA |
BLOB |
TIMESTAMP |
DATETIME |
TIMESTAMP DENGAN ZONA WAKTU |
DATETIME |
DATE |
DATE |
TIME |
TIME |
TIME WITH TIME ZONE |
TIME |
INTERVAL |
STRING (128)—1 TAHUN, 2 BULAN, 3 HARI, 4 JAM, 5 MENIT, 6 DETIK |
BOOLEAN |
CHAR (5) salah atau benar |
ENUM |
STRING (64) |
CIDR |
STRING (50) |
INET |
STRING (50) |
MACADDR |
STRING (18) |
BIT (n) |
STRING (n) |
BIT VARYING |
STRING (n) |
UUID |
STRING |
TSVECTOR |
CLOB |
TSQUERY |
CLOB |
XML |
CLOB |
POINT |
STRING (255) “(x,y)” |
LINE |
STRING (255) “(x,y,z)” |
LSEG |
STRING (255) “((x1,y1),(x2,y2))” |
BOX |
STRING (255) “((x1,y1),(x2,y2))” |
PATH |
CLOB “((x1,y1),(xn,yn))” |
POLYGON |
CLOB “((x1,y1),(xn,yn))” |
CIRCLE |
STRING (255) “(x,y),r” |
JSON |
NCLOB |
JSONB |
NCLOB |
ARRAY |
NCLOB |
COMPOSITE |
NCLOB |
HSTORE |
NCLOB |
INT4JANGKAUAN |
STRING (255) |
INT8JANGKAUAN |
STRING (255) |
NUMRANGE |
STRING (255) |
STRRANGE |
STRING (255) |
Menggunakan jenis data sumber LOB untuk PostgreSQL
Ukuran kolom PostgreSQL memengaruhi konversi jenis data LOB PostgreSQL ke jenis data AWS DMS . Untuk menggunakannya, ambil langkah-langkah berikut untuk jenis data AWS DMS berikut:
-
BLOB - Atur Batas ukuran LOB hingga nilai Ukuran LOB maksimum (KB) pada saat pembuatan tugas.
-
CLOB — Replikasi menangani setiap karakter sebagai UTF8 karakter. Oleh karena itu, temukan panjang teks karakter terpanjang di kolom, yang ditunjukkan di sini sebagai
max_num_chars_text
. Gunakan panjang ini untuk menentukan nilai untuk Batasi ukuran LOB ke. Jika data memuat karakter 4-byte, kalikan dengan 2 untuk menentukan nilai Batas ukuran LOB hingga, yang dalam bentuk byte. Dalam kasus ini, Batas ukuran LOB hingga sama denganmax_num_chars_text
dikalikan dengan 2. -
NCLOB - Replikasi menangani setiap karakter sebagai karakter double-byte. Oleh karena itu, cari panjang teks karakter terpanjang di kolom (
max_num_chars_text
) dan kalikan dengan 2. Anda melakukan ini untuk menentukan nilai untuk Batasi ukuran LOB ke. Dalam kasus ini, Batas ukuran LOB hingga sama denganmax_num_chars_text
dikalikan dengan 2. Jika data memuat karakter 4-byte, kalikan dengan 2 lagi. Dalam kasus ini, Batas ukuran LOB hingga sama denganmax_num_chars_text
dikalikan dengan 4.