Bekerja dengan database SQL Postgre yang dikelola sendiri Bekerja dengan database AWS SQL Postgre yang dikelola Menggunakan replikasi logis untuk mengaktifkan CDC selama migrasi Menggunakan titik CDC awal asli untuk mengatur CDC beban Migrasi Postgre SQL ke Postgre SQL Migrasi dari Babelfish Menghapus artefak dari sumber Postgre SQL Pengaturan konfigurasi lanjutan untuk Postgre SQL sebagai sumber Menggunakan pengaturan titik akhir MapBooleanAsBoolean Postgre SQL Titik akhir dan pengaturan ECA Keterbatasan Postgre SQL sebagai sumber Tipe data sumber untuk Postgre SQL

Menggunakan SQL database Postgre sebagai sumber AWS DMS

Anda dapat memigrasikan data dari satu atau banyak database Postgre menggunakanSQL. AWS DMS Dengan SQL database Postgre sebagai sumber, Anda dapat memigrasikan data ke database Postgre lain atau salah satu SQL database lain yang didukung.

Untuk informasi tentang versi Postgre SQL yang AWS DMS mendukung sebagai sumber, lihat. Sumber untuk AWS DMS

AWS DMS mendukung Postgre SQL untuk jenis database ini:

Basis data on-premise
Database pada instans Amazon EC2
Database pada instans Amazon RDS DB
Database pada instans DB berdasarkan Amazon Aurora SQL Postgre -Compatible Edition
Database pada instans DB berdasarkan Amazon Aurora SQL Postgre -Compatible Serverless Edition

catatan

DMSmendukung Amazon Aurora Postgre SQL —Serverless V1 sebagai sumber untuk Full load saja. Tetapi Anda dapat menggunakan Amazon Aurora Postgre SQL —Serverless V2 sebagai sumber untuk Full load, Full load +, dan hanya tugas. CDC CDC

Versi sumber Postgre SQL	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 Secure Socket Layers (SSL) untuk mengenkripsi koneksi antara SQL titik akhir Postgre dan instance replikasi. Untuk informasi lebih lanjut tentang penggunaan SSL dengan SQL titik akhir Postgre, lihat. Menggunakan SSL dengan AWS Database Migration Service

Sebagai persyaratan keamanan tambahan saat menggunakan Postgre SQL sebagai sumber, akun pengguna yang ditentukan harus merupakan pengguna terdaftar di database SQL Postgre.

Untuk mengkonfigurasi SQL database Postgre sebagai titik akhir AWS DMS sumber, lakukan hal berikut:

Buat SQL pengguna Postgre dengan izin yang sesuai untuk menyediakan AWS DMS akses ke database sumber SQL Postgre Anda.
catatan
- Jika database SQL sumber Postgre Anda dikelola sendiri, lihat Bekerja dengan SQL database Postgre yang dikelola sendiri sebagai sumber di AWS DMS untuk informasi selengkapnya.
- Jika database SQL sumber Postgre Anda dikelola oleh AmazonRDS, lihat Bekerja dengan SQL database Postgre yang AWS dikelola sebagai sumber DMS untuk informasi selengkapnya.
Buat titik akhir SQL sumber Postgre yang sesuai dengan konfigurasi database Postgre pilihan Anda. SQL
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 mengubah pengambilan data (CDC-only atau full load dan CDC task), lihat Mengaktifkan CDC menggunakan database Postgre SQL yang dikelola sendiri sebagai sumber AWS DMS atau. Mengaktifkan CDC dengan instans AWS SQL Postgre DB yang dikelola dengan AWS DMS

Topik

Bekerja dengan SQL database Postgre yang dikelola sendiri sebagai sumber di AWS DMS
Bekerja dengan SQL database Postgre yang AWS dikelola sebagai sumber DMS
Mengaktifkan change data capture (CDC) menggunakan replikasi logis
Menggunakan titik CDC awal asli untuk mengatur CDC beban sumber Postgre SQL
Migrasi dari Postgre ke Postgre menggunakan SQL SQL AWS DMS
Bermigrasi dari Babelfish untuk Amazon Aurora Postgre menggunakan SQL AWS DMS
Menghapus AWS DMS artefak dari database sumber Postgre SQL
Pengaturan konfigurasi tambahan saat menggunakan SQL database Postgre sebagai sumber DMS
Menggunakan pengaturan titik akhir MapBooleanAsBoolean Postgre SQL
Pengaturan titik akhir dan Atribut Koneksi Ekstra (ECAs) saat menggunakan Postgre SQL sebagai sumber DMS
Keterbatasan dalam menggunakan SQL database Postgre sebagai sumber DMS
Tipe data sumber untuk Postgre SQL

Bekerja dengan SQL database Postgre yang dikelola sendiri sebagai sumber di AWS DMS

Dengan SQL database Postgre yang dikelola sendiri sebagai sumber, Anda dapat memigrasikan data ke database Postgre lain, atau salah satu SQL database target lain yang didukung oleh. AWS DMS Sumber database dapat berupa database lokal atau mesin yang dikelola sendiri yang berjalan pada instans AmazonEC2. Anda dapat menggunakan instans DB untuk tugas beban penuh dan mengubah tugas pengambilan data (CDC).

Prasyarat untuk menggunakan database Postgre yang dikelola sendiri sebagai sumber SQL AWS DMS

Sebelum memigrasi data dari database SQL sumber Postgre yang dikelola sendiri, lakukan hal berikut:

Pastikan Anda menggunakan SQL database Postgre yang versi 9.4.x atau lebih tinggi.
Untuk CDC tugas plus beban penuh atau tugas CDC -only, berikan izin pengguna super untuk akun pengguna yang ditentukan untuk database sumber Postgre. SQL Akun pengguna membutuhkan izin pengguna super untuk mengakses fungsi khusus replikasi dalam sumber. Untuk tugas yang hanya memuat penuh, akun pengguna memerlukan SELECT izin pada tabel untuk memigrasikannya.
Tambahkan alamat IP server AWS DMS replikasi ke file pg_hba.conf konfigurasi dan aktifkan koneksi replikasi dan 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 pg_hba.conf konfigurasi SQL Postgre mengontrol otentikasi klien. (HBAsingkatan dari otentikasi berbasis host.) 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 Postgre SQL yang dikelola sendiri sebagai sumber AWS DMS

catatan

Beberapa AWS DMS transaksi menganggur selama beberapa waktu sebelum DMS mesin menggunakannya lagi. Dengan menggunakan parameter idle_in_transaction_session_timeout di Postgre SQL versi 9.6 dan yang lebih tinggi, Anda dapat menyebabkan transaksi idle menjadi time out dan gagal. Jangan mengakhiri transaksi yang diam saat Anda menggunakan AWS DMS.

Mengaktifkan CDC menggunakan database Postgre SQL yang dikelola sendiri sebagai sumber AWS DMS

AWS DMS mendukung perubahan pengambilan data (CDC) menggunakan replikasi logis. Untuk mengaktifkan replikasi logis dari database SQL sumber Postgre yang dikelola sendiri, tetapkan parameter dan nilai berikut dalam file konfigurasi: postgresql.conf

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 dibuat slot.
Atur max_wal_senders menjadi nilai yang lebih besar dari 1.

Parametermax_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 SQL database Postgre 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, DMS tugas 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 DMS replikasi.

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 SQL database Postgre) diabaikan sampai server dimulai ulang. RDS Untuk informasi lebih lanjut, lihat dokumentasi Postgre SQL.

Untuk informasi selengkapnya tentang mengaktifkanCDC, lihatMengaktifkan change data capture (CDC) menggunakan replikasi logis.

Bekerja dengan SQL database Postgre yang AWS dikelola sebagai sumber DMS

Anda dapat menggunakan instans Postgre SQL DB AWS-managed sebagai sumber untuk. AWS DMS Anda dapat melakukan tugas beban penuh dan mengubah tugas pengambilan data (CDC) menggunakan sumber SQL Postgre AWS-managed.

Prasyarat untuk menggunakan database Postgre AWS-managed sebagai sumber SQL DMS

Sebelum memigrasi data dari database SQL sumber Postgre yang AWS dikelola, lakukan hal berikut:

Kami menyarankan Anda menggunakan akun AWS pengguna dengan izin minimum yang diperlukan untuk instans Postgre SQL DB sebagai akun pengguna untuk titik akhir sumber SQL Postgre. AWS DMS Menggunakan akun master tidak disarankan. Akun harus memiliki rds_superuser peran dan rds_replication peran. Peran rds_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 Migrasi SQL database Amazon RDS untuk Postgre tanpa menggunakan akun pengguna master.
Jika database sumber Anda berada di virtual private cloud (VPC), pilih grup VPC keamanan yang menyediakan akses ke instans DB tempat database berada. Ini diperlukan agar instance DMS replikasi berhasil terhubung ke instance DB sumber. Ketika database dan instance DMS replikasi samaVPC, tambahkan grup keamanan yang sesuai ke aturan inboundnya sendiri.

catatan

Mengaktifkan CDC dengan instans AWS SQL Postgre DB yang dikelola dengan AWS DMS

AWS DMS mendukung SQL database CDC Amazon RDS Postgre ketika instans DB dikonfigurasi untuk menggunakan replikasi logis. Tabel berikut merangkum kompatibilitas replikasi logis dari setiap versi Postgre AWS-managed. SQL

Anda tidak dapat menggunakan replika SQL baca RDS Postgre untuk CDC (replikasi berkelanjutan).

Versi Postgre SQL	AWS DMS dukungan beban penuh	Dukungan AWS DMS CDC
Aurora Postgre SQL versi 2.1 dengan kompatibilitas Postgre 10.5 (atau lebih rendah) SQL	Ya	Tidak
Aurora Postgre SQL versi 2.2 dengan kompatibilitas Postgre 10.6 (atau lebih tinggi) SQL	Ya	Ya
RDSuntuk Postgre SQL dengan kompatibilitas Postgre SQL 10.21 (atau lebih tinggi)	Ya	Ya

Untuk mengaktifkan replikasi logis untuk instance RDS Postgre SQL DB

Gunakan akun pengguna AWS master untuk instance Postgre SQL DB sebagai akun pengguna untuk titik akhir sumber SQL Postgre. Akun pengguna master memiliki peran yang diperlukan yang memungkinkannya untuk diaturCDC.

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 Migrasi SQL database Amazon RDS untuk Postgre tanpa menggunakan akun pengguna master.
Atur rds.logical_replication parameter dalam grup CLUSTER parameter DB Anda ke 1. Parameter statis memerlukan reboot dari instans DB agar menjadi berpengaruh. Sebagai bagian dari penerapan parameter ini, AWS DMS menetapkan parameter wal_level, max_wal_senders, max_replication_slots, dan max_connections. Perubahan parameter ini dapat meningkatkan pembuatan write ahead log (WAL), jadi hanya setel rds.logical_replication saat Anda menggunakan slot replikasi logis.
Parameter wal_sender_timeout mengakhiri sambungan replikasi yang tidak aktif lebih lama dari jumlah milidetik tertentu. Default untuk SQL database Postgre 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, DMS tugas 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 DMS replikasi.
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 menetapkan max_worker_processes lebih tinggi dari nilai default.
Saat menggunakan Aurora Postgre SQL sebagai sumber denganCDC, atur ke. synchronous_commit ON

Migrasi SQL database Amazon RDS untuk Postgre tanpa menggunakan akun pengguna master

Dalam beberapa kasus, Anda mungkin tidak menggunakan akun pengguna utama untuk instans Amazon RDS Postgre SQL DB yang Anda gunakan sebagai sumber. Dalam kasus ini, Anda membuat beberapa objek untuk menangkap peristiwa bahasa definisi data (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 Postgre SQL DB menggunakan akun pengguna selain akun master, di sini akunnya. OtherThanMaster

Buat tabel awsdms_ddl_audit dengan menjalankan perintah berikut, menggantiobjects_schema dalam kode berikut dengan nama skema untuk yang digunakan.



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 objects_schema dalam kode berikut dengan nama skema untuk yang digunakan.



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 into objects_schema.awsdms_ddl_audit
         values
         (
         default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
         );
         delete from objects_schema.awsdms_ddl_audit;
end if;
END;
$$;

Keluar dari akun OtherThanMaster dan masuk dengan akun yang memiliki peran rds_superuser yang ditentukan akun itu.

Buat pemicu peristiwabawsdms_intercept_ddl dengan menjalankan perintah berikut.



CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end 
EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();

Pastikan semua pengguna dan peran yang mengakses acara ini memiliki DDL izin 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 SQL Postgre untuk mengaktifkan change data capture (CDC) selama migrasi database untuk sumber Postgre. SQL Anda dapat menggunakan fitur ini dengan Postgre yang dikelola sendiri SQL dan juga Amazon RDS untuk instans DB SQL SQL Postgre. Pendekatan ini mengurangi downtime dan membantu memastikan bahwa database target sinkron dengan database SQL Postgre sumber.

AWS DMS mendukung CDC untuk SQL tabel Postgre dengan kunci utama. Jika tabel tidak memiliki kunci utama, write-ahead logs (WAL) tidak menyertakan gambar sebelumnya dari baris database. 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 saat menggunakan SQL database Postgre sebagai sumber DMS.

catatan

REPLICAIDENTITYFULLdidukung dengan plugin decoding logis, tetapi tidak didukung dengan plugin pglogical. Untuk informasi lebih lanjut, lihat dokumentasi pglogical.

Untuk beban penuh CDC dan CDC hanya tugas, AWS DMS gunakan slot replikasi logis untuk menyimpan WAL log untuk replikasi hingga log diterjemahkan. Saat restart (bukan melanjutkan) untuk beban penuh dan CDC tugas atau CDC tugas, slot replikasi akan dibuat ulang.

catatan

Untuk decoding logis, DMS gunakan test_decoding atau plugin pglogical. Jika plugin pglogical tersedia pada SQL database Postgre sumber, DMS buat slot replikasi menggunakan pglogical, jika tidak plugin test_decoding digunakan. Untuk informasi selengkapnya tentang plugin test_decoding, lihat Dokumentasi Postgre. SQL

Jika parameter database max_slot_wal_keep_size diatur ke nilai non default, dan slot replikasi berada di belakang arus LSN dengan lebih dari ukuran ini, DMS tugas gagal karena penghapusan WAL file yang diperlukan. restart_lsn

Mengonfigurasi plugin pglogical

Diimplementasikan sebagai SQL ekstensi Postgre, plugin pglogical adalah sistem replikasi logis dan model untuk replikasi data selektif. Tabel berikut mengidentifikasi sumber Postgre SQL database versi yang mendukung plugin pglogical.

Sumber Postgre SQL	Mendukung pglogical
Postgre SQL 9.4 yang dikelola sendiri atau lebih tinggi	Ya
Amazon RDS Postgre SQL 9.5 atau lebih rendah	Tidak
Amazon RDS Postgre SQL 9.6 atau lebih tinggi	Ya
Aurora SQL Postgre 1.x hingga 2.5.x	Tidak
Aurora SQL Postgre 2.6.x atau lebih tinggi	Ya
Aurora SQL Postgre 3.3.x atau lebih tinggi	Ya

Sebelum mengonfigurasi pglogical untuk digunakan dengan AWS DMS, pertama-tama aktifkan replikasi logis untuk change data capture (CDC) pada database sumber Postgre Anda. SQL

Untuk informasi tentang mengaktifkan replikasi logis untuk database sumber CDC SQL Postgre yang dikelola sendiri, lihat Mengaktifkan CDC menggunakan database Postgre SQL yang dikelola sendiri sebagai sumber AWS DMS
Untuk informasi tentang mengaktifkan replikasi logis untuk CDC database sumber Postgre SQL yang AWS dikelola, lihat. Mengaktifkan CDC dengan instans AWS SQL Postgre DB yang dikelola dengan AWS DMS

Setelah replikasi logis diaktifkan pada database SQL sumber Postgre Anda, gunakan langkah-langkah berikut untuk mengonfigurasi pglogical untuk digunakan dengan. DMS

Untuk menggunakan plugin pglogical untuk replikasi logis pada database sumber SQL Postgre dengan AWS DMS

Buat ekstensi pglogical pada database SQL Postgre sumber Anda:
1. Atur parameter yang benar:
  - Untuk database Postgre yang dikelola sendiri, atur parameter SQL database. shared_preload_libraries= 'pglogical'
  - Untuk database Postgre di SQL Amazon RDS dan Amazon Aurora SQL Postgre -Compatible Edition, atur parameter ke shared_preload_libraries dalam grup parameter yang sama. pglogical RDS
2. Mulai ulang basis data SQL sumber Postgre Anda.
3. Pada SQL database Postgre, 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 SQL sumber Postgre Anda.

catatan

Jika Anda tidak mengaktifkan pglogical pada database SQL sumber Postgre Anda, AWS DMS gunakan plugin secara default. test_decoding Ketika pglogical diaktifkan untuk decoding logis, AWS DMS gunakan pglogical secara default. Tapi Anda dapat mengatur atribut sambungan tambahan, PluginNameuntuk menggunakan plugin test_decoding sebagai gantinya.

Menggunakan titik CDC awal asli untuk mengatur CDC beban sumber Postgre SQL

Untuk mengaktifkan titik CDC awal asli dengan Postgre SQL sebagai sumber, atur atribut koneksi slotName tambahan ke nama slot replikasi logis yang ada saat 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.

Postgre SQL menulis perubahan database ke WAL file 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 menyarankan Anda mengatur alarm penggunaan ruang di SQL instance Postgre sumber saat 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 Postgre SQL sebagai sumber DMS.

Prosedur berikut melalui pendekatan ini secara lebih rinci.

Untuk menggunakan titik CDC awal asli untuk menyiapkan CDC beban titik akhir sumber Postgre SQL

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 CDC -only baru menggunakan konsol, AWS CLI atau AWS DMS API. Misalnya, menggunakan CLI Anda mungkin menjalankan create-replication-task perintah 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 dan replication-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 tampilan pg_replication_slotspada 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 CDC mulai khusus saat membuat tugas CDC -only baru menggunakan AWS DMS konsol, lakukan hal berikut:
- Di bagian Pengaturan tugas, untuk mode CDC mulai untuk transaksi sumber, pilih Aktifkan mode CDC mulai kustom.
- Untuk titik CDC awal kustom untuk transaksi sumber, pilih Tentukan nomor urutan log. Tentukan nomor perubahan sistem atau pilih Tentukan pos pemeriksaan pemulihan, dan berikan pos pemeriksaan Pemulihan.
Saat CDC tugas ini berjalan, AWS DMS menimbulkan 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.

Saat menggunakan titik CDC awal asli dengan plugin pglogical dan Anda ingin menggunakan slot replikasi baru, selesaikan langkah-langkah pengaturan berikut sebelum membuat tugas. CDC

Untuk menggunakan slot replikasi baru yang sebelumnya tidak dibuat sebagai bagian dari tugas lain DMS

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 CDC Mulai Asli untuk CDC tugas 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);

Setel atribut koneksi tambahan (ECA) berikut saat Anda membuat titik akhir sumber Anda.
```
PluginName=PGLOGICAL;slotName=slot_name;
                    
```

Anda sekarang dapat membuat CDC satu-satunya tugas dengan titik awal SQL asli Postgre menggunakan slot replikasi baru. Untuk informasi lebih lanjut tentang plugin pglogical, lihat dokumentasi pglogical 3.7

Migrasi dari Postgre ke Postgre menggunakan SQL SQL AWS DMS

Ketika Anda bermigrasi dari mesin database selain Postgre SQL ke SQL database Postgre, hampir selalu AWS DMS merupakan alat migrasi terbaik untuk digunakan. Tetapi ketika Anda bermigrasi dari database Postgre ke SQL database Postgre, alat Postgre SQL bisa lebih efektifSQL.

Menggunakan alat SQL asli Postgre untuk memigrasi data

Kami menyarankan Anda menggunakan alat migrasi SQL database Postgre seperti dalam pg_dump kondisi berikut:

Anda memiliki migrasi homogen, di mana Anda bermigrasi dari database Postgre sumber ke SQL database Postgre target. SQL
Anda memigrasi seluruh basis data.
Alat asli mengizinkan Anda untuk memigrasi data Anda dengan waktu downtime minimal.

Utilitas pg_dump menggunakan COPY perintah untuk membuat skema dan dump data dari database Postgre. SQL 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 SQL sumber Postgre yang berjalan ke SQL target Amazon RDS untuk Postgre, Anda dapat EC2 menggunakan plugin pglogical.

Untuk informasi selengkapnya tentang mengimpor database Postgre SQL ke Amazon RDS untuk Postgre atau SQL Amazon Aurora Postgre -Compatible Edition, lihat. SQL https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html

Menggunakan DMS untuk memigrasi data dari Postgre ke Postgre SQL SQL

AWS DMS dapat memigrasikan data, misalnya, dari SQL database Postgre sumber yang ada di lokasi ke Amazon RDS target untuk instance Postgre SQL atau Aurora Postgre. SQL Tipe SQL data inti atau dasar Postgre paling sering berhasil bermigrasi.

catatan

Saat mereplikasi tabel yang dipartisi dari SQL sumber Postgre ke SQL target Postgre, Anda tidak perlu menyebutkan tabel induk sebagai bagian dari kriteria pemilihan 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 tipe data, seperti XML danJSON, dapat berhasil bermigrasi sebagai file kecil tetapi dapat gagal jika mereka adalah dokumen besar.

Saat melakukan migrasi jenis data, perhatikan hal-hal berikut:

Dalam beberapa kasus, tipe data Postgre SQL NUMERIC (p, s) tidak menentukan presisi dan skala apa pun. Untuk DMS versi 3.4.2 dan sebelumnya, DMS menggunakan presisi 28 dan skala 6 secara default, NUMERIC (28,6). Misalnya, nilai 0.611111104488373 dari sumber dikonversi ke 0.611111 pada target Postgre. SQL
Tabel dengan tipe ARRAY data harus memiliki kunci utama. Tabel dengan tipe ARRAY data yang kehilangan kunci utama akan ditangguhkan selama pemuatan penuh.

Tabel berikut menunjukkan tipe SQL data Postgre sumber dan apakah mereka dapat dimigrasi dengan sukses.

Tipe 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			Posting tipe data GIS spasial
LINE			X
LSEG			X
BOX			X
PATH			X
POLYGON	X			Posting tipe data GIS spasial
CIRCLE			X
JSON		X
ARRAY	X			Memerlukan Kunci Primer
COMPOSITE			X
RANGE			X
LINESTRING	X			Posting tipe data GIS spasial
MULTIPOINT	X			Posting tipe data GIS spasial
MULTILINESTRING	X			Posting tipe data GIS spasial
MULTIPOLYGON	X			Posting tipe data GIS spasial
GEOMETRYCOLLECTION	X			Posting tipe data GIS spasial

Migrasi tipe data GIS spasial Post

Data spasial mengidentifikasi informasi geometri dari suatu objek atau lokasi di ruang. Database SQL relasional objek Postgre mendukung tipe data spasial Post. GIS

Sebelum memigrasikan objek data SQL spasial Postgre, pastikan GIS plugin Post diaktifkan di tingkat global. Melakukan hal ini memastikan bahwa AWS DMS menciptakan kolom data spasial sumber yang tepat untuk instance DB SQL target Postgre.

Untuk migrasi SQL homogen Postgre SQL ke Postgre, AWS DMS mendukung migrasi tipe dan subtipe objek data Post GIS geometris dan geografis (koordinat geodetik) seperti berikut ini:

POINT
LINESTRING
POLYGON
MULTIPOINT
MULTILINESTRING
MULTIPOLYGON
GEOMETRYCOLLECTION

Bermigrasi dari Babelfish untuk Amazon Aurora Postgre menggunakan SQL AWS DMS

Anda dapat memigrasikan tabel SQL sumber Babelfish untuk Aurora Postgre ke titik akhir target yang didukung menggunakan. AWS DMS

Saat membuat titik akhir AWS DMS sumber menggunakan DMS konsol, atau CLI perintahAPI, Anda menyetel sumber ke Amazon Aurora SQL Postgre, dan nama database ke. babelfish_db Di bagian Pengaturan Titik Akhir, pastikan bahwa DatabaseModediatur ke Babelfish, dan BabelfishDatabaseNamediatur ke nama sumber Babelfish T- database. SQL Alih-alih menggunakan port Babelfish1433, gunakan TCP port Aurora Postgre. SQL TCP 5432

Anda harus membuat tabel sebelum memigrasi data untuk memastikannya 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 Anda

Saat Anda membuat tugas migrasi untuk sumber Babelfish, Anda perlu menyertakan aturan transformasi yang memastikan bahwa DMS menggunakan tabel target yang telah dibuat sebelumnya.

Jika Anda menyetel mode migrasi multi-database saat menentukan SQL klaster Babelfish for Postgre, tambahkan aturan transformasi yang mengganti nama skema menjadi skema T-. SQL Misalnya, jika nama SQL skema T- adalahdbo, dan nama skema Babelfish untuk Postgre Andamydb_dbo, ganti nama SQL skema menjadi menggunakan aturan transformasi. dbo Untuk menemukan nama SQL skema Postgre, 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 SQL skema Postgre memiliki one-to-one pemetaan ke nama skema dalam T-database. 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 SQL sumber Postgre dengan tabel Babelfish

Batasan berikut berlaku saat menggunakan titik akhir SQL sumber Postgre dengan tabel Babelfish:

DMShanya mendukung migrasi dari Babelfish versi 16.2/15.6 dan yang lebih baru, dan versi 3.5.3 dan yang lebih baru. DMS
DMStidak 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 BYTEA data, DMS mengonversinya menjadi tipe varbinary(max) data saat bermigrasi ke SQL Server sebagai target.
DMStidak mendukung LOB mode Penuh untuk tipe data biner. Gunakan LOB mode terbatas untuk tipe data biner sebagai gantinya.
DMStidak 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 yang sedang berlangsung (CDCatau Full load andCDC), setel atribut koneksi PluginName tambahan (ECA) keTEST_DECODING.
DMStidak mendukung replikasi (CDCatau Muat penuh danCDC) tabel yang dipartisi untuk Babelfish sebagai sumber.

Menghapus AWS DMS artefak dari database sumber Postgre SQL

Untuk menangkap DDL peristiwa, AWS DMS buat berbagai artefak dalam SQL database Postgre 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 saat menggunakan SQL database Postgre sebagai sumber DMS

Anda dapat menambahkan pengaturan konfigurasi tambahan saat memigrasi data dari SQL database Postgre dengan dua cara:

Anda dapat menambahkan nilai ke atribut koneksi tambahan untuk menangkap DDL peristiwa dan untuk menentukan skema di mana artefak DDL database operasional dibuat. Untuk informasi selengkapnya, lihat Pengaturan titik akhir dan Atribut Koneksi Ekstra (ECAs) saat menggunakan Postgre SQL 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 REPLICA IDENTITY di Postgre SQL versi 9.4 dan yang lebih tinggi, Anda dapat mengontrol informasi yang ditulis ke log tulis (). WALs Secara khusus, ia melakukannya untuk WALs mengidentifikasi baris yang diperbarui atau dihapus. REPLICA IDENTITY FULLmencatat nilai lama dari semua kolom di baris. Gunakan REPLICA IDENTITY FULL dengan hati-hati untuk setiap tabel karena FULL menghasilkan jumlah tambahan WALs yang mungkin tidak diperlukan. Untuk informasi lebih lanjut, lihat ALTERTABLE- REPLICA IDENTITY

Menggunakan pengaturan titik akhir MapBooleanAsBoolean Postgre SQL

Anda dapat menggunakan pengaturan SQL titik akhir Postgre untuk memetakan boolean sebagai boolean dari sumber Postgre Anda SQL ke target Amazon Redshift. Secara default, BOOLEAN tipe dimigrasikan sebagai varchar (5). Anda dapat menentukan MapBooleanAsBoolean untuk membiarkan Postgre SQL memigrasi 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 My SQL tidak memiliki BOOLEAN tipe, gunakan aturan transformasi daripada setelan ini saat memigrasikan BOOLEAN data ke MySQL.

Pengaturan titik akhir dan Atribut Koneksi Ekstra (ECAs) saat menggunakan Postgre SQL sebagai sumber DMS

Anda dapat menggunakan pengaturan titik akhir dan atribut koneksi tambahan (ECAs) untuk mengonfigurasi database sumber Postgre SQL 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 '{"EndpointSetting": "value", ...}' JSON

Tabel berikut menunjukkan pengaturan titik akhir dan ECAs yang dapat Anda gunakan dengan Postgre SQL sebagai sumber.

Nama atribut	Deskripsi
`CaptureDdls`	Untuk menangkap DDL peristiwa, AWS DMS buat berbagai artefak di SQL database Postgre saat tugas dimulai. Anda nantinya dapat menghapus artefak ini seperti yang dijelaskan di Menghapus AWS DMS artefak dari database sumber Postgre SQL. Jika nilai ini disetel ke false, Anda tidak perlu membuat tabel atau pemicu pada database sumber. DDLAcara streaming ditangkap. Nilai default: `true` Nilai yang benar: benar/salah Contoh: `--postgre-sql-settings '{"CaptureDdls": true}'`
`ConsumeMonotonicEvents`	Digunakan untuk mengontrol bagaimana transaksi monolitik dengan duplikat Log Sequence Numbers (LSNs) direplikasi. Ketika parameter ini`false`, peristiwa dengan duplikat LSNs dikonsumsi dan direplikasi pada target. Ketika parameter ini`true`, hanya peristiwa pertama yang direplikasi sementara peristiwa dengan duplikat LSNs tidak dikonsumsi atau direplikasi pada target. Nilai default: `false` Nilai yang benar: salah/benar Contoh: `--postgre-sql-settings '{"ConsumeMonotonicEvents": true}'`
`DdlArtifactsSchema`	Menetapkan skema di mana artefak DDL database operasional dibuat. Nilai default: publik Nilai yang benar: String Contoh: `--postgre-sql-settings '{"DdlArtifactsSchema": "xyzddlschema"}'`
`DisableUnicodeSourceFilter`	Menonaktifkan filter sumber Unicode dengan PostgreSQL, untuk nilai yang diteruskan ke filter aturan Pemilihan 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: `--postgre-sql-settings '{"DisableUnicodeSourceFilter": "true"}'`
`ExecuteTimeout`	Menetapkan batas waktu pernyataan klien untuk SQL instance Postgre, dalam hitungan detik. Nilai default adalah 60 detik. Contoh: `--postgre-sql-settings '{"ExecuteTimeout": 100}'`
`FailTasksOnLobTruncation`	Ketika diatur ke`true`, nilai ini menyebabkan tugas gagal jika ukuran sebenarnya dari LOB kolom lebih besar dari yang ditentukan`LobMaxSize`. Jika tugas diatur ke LOB mode Terbatas dan opsi ini disetel ke true, tugas gagal alih-alih memotong data. LOB Nilai default: salah Nilai yang benar: Boolean Contoh: `--postgre-sql-settings '{"FailTasksOnLobTruncation": true}'`
`fetchCacheSize`	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: `10000` Nilai yang benar: Angka ECAContoh: `fetchCacheSize=10000;`
`HeartbeatEnable`	Fitur WAL detak jantung meniru transaksi tiruan, sehingga slot replikasi logis idle tidak memegang WAL log lama yang menghasilkan situasi penyimpanan penuh pada sumbernya. Heartbeat ini terus membuat `restart_lsn` bergerak dan mencegah skenario penyimpanan penuh. Nilai default: `false` Nilai yang benar: benar/salah Contoh: `--postgre-sql-settings '{"HeartbeatEnable": true}'`
`HeartbeatFrequency`	Mengatur frekuensi WAL detak jantung (dalam hitungan menit). Nilai default: `5` Nilai yang benar: Angka Contoh: `--postgre-sql-settings '{"HeartbeatFrequency": 1}'`
`HeartbeatSchema`	Menetapkan skema di mana artefak heartbeat dibuat. Nilai default: `public` Nilai yang benar: String Contoh: `--postgre-sql-settings '{"HeartbeatSchema": "xyzheartbeatschema"}'`
`MapJsonbAsClob`	Secara default, AWS DMS peta JSONB keNCLOB. Anda dapat menentukan `MapJsonbAsClob` untuk membiarkan Postgre SQL memigrasi tipe sebagai. JSONB CLOB Contoh: `--postgre-sql-settings='{"MapJsonbAsClob": "true"}'`
`MapLongVarcharAs`	Secara default, AWS DMS peta VARCHAR keWSTRING. Anda dapat menentukan `MapLongVarcharAs` untuk membiarkan Postgre SQL memigrasikan tipe VARCHAR (N) (di mana N lebih besar dari 16387) ke jenis berikut: WSTRING CLOB NCLOB Contoh: `--postgre-sql-settings='{"MapLongVarcharAs": "CLOB"}'`
`MapUnboundedNumericAsString`	Parameter ini memperlakukan kolom dengan tipe NUMERIC data tak terbatas agar berhasil bermigrasi tanpa kehilangan presisi nilai numerik. STRING Gunakan parameter ini hanya untuk replikasi dari SQL sumber Postgre ke SQL target Postgre, atau database dengan kompatibilitas Postgre. SQL Nilai default: `false` Nilai valid: `false`/`true` Contoh: `--postgre-sql-settings '{"MapUnboundedNumericAsString": true}'` 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 yang lebih tinggi catatan Hanya gunakan `MapUnboundedNumericAsString` di SQL sumber Postgre dan titik akhir target bersama-sama. Penggunaan SQL titik akhir Postgre `MapUnboundedNumericAsString` pada sumber membatasi presisi hingga 28 selama. CDC Penggunaan `MapUnboundedNumericAsString` pada titik akhir target, memigrasikan data dengan Precision 28 Scale 6. Jangan gunakan `MapUnboundedNumericAsString` dengan target non-PostGRESQL.
`PluginName`	Menentukan plugin yang digunakan untuk membuat slot replikasi. Nilai yang valid: `pglogical`, `test_decoding` Contoh: `--postgre-sql-settings '{"PluginName": "test_decoding"}'`
`SlotName`	Menetapkan nama slot replikasi logis yang dibuat sebelumnya untuk CDC memuat instance sumber PostgreSQL. Ketika digunakan dengan parameter AWS DMS API `CdcStartPosition` permintaan, atribut ini juga memungkinkan menggunakan titik CDC awal asli. DMSmemverifikasi bahwa slot replikasi logis yang ditentukan ada sebelum memulai tugas CDC pemuatan. Hal ini juga memverifikasi bahwa tugas dibuat dengan pengaturan `CdcStartPosition` yang valid. Jika slot yang ditentukan tidak ada atau tugas tidak memiliki `CdcStartPosition` pengaturan yang valid, DMS menimbulkan kesalahan. Untuk informasi selengkapnya tentang pengaturan parameter permintaan `CdcStartPosition`, lihat Menentukan titik awal CDC asli. Untuk informasi selengkapnya tentang penggunaan`CdcStartPosition`, lihat dokumentasi untuk`CreateReplicationTask`,`StartReplicationTask`, dan `ModifyReplicationTask` API operasi di AWS Database Migration Service APIReferensi. Nilai valid: String Contoh: `--postgre-sql-settings '{"SlotName": "abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef"}'`
`unboundedVarcharMaxSize`	Atribut Koneksi Ekstra (ECA) ini mendefinisikan ukuran maksimum kolom data yang didefinisikan sebagai tipe VarChar tanpa penentu panjang maksimum. Defaultnya adalah 8000 byte. Nilai maksimum adalah 10485760 byte.

Keterbatasan dalam menggunakan SQL database Postgre sebagai sumber DMS

Keterbatasan berikut berlaku saat menggunakan Postgre SQL sebagai sumber untuk: AWS DMS

AWS DMS tidak berfungsi dengan Amazon RDS untuk Postgre SQL 10.4 atau Amazon Aurora Postgre 10.4 baik sebagai sumber atau targetSQL.
Tabel yang ditangkap harus memiliki kunci primer. Jika tabel tidak memiliki kunci utama, AWS DMS abaikan DELETE dan UPDATE rekam operasi untuk tabel tersebut. Sebagai solusinya, lihat Mengaktifkan change data capture (CDC) menggunakan replikasi logis.

Catatan: Kami tidak menyarankan migrasi tanpa Kunci Primer/Indeks Unik, jika tidak, batasan tambahan berlaku seperti kemampuan penerapan Batch “TIDAK”, LOB kemampuan 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 pembaruan kunci utama di Postgre tidak dapat SQL 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, tabel1TABLE1, dan Tabel1) dapat menyebabkan perilaku yang tidak dapat diprediksi. Karena masalah ini, AWS DMS tidak mendukung jenis replikasi ini.
Dalam kebanyakan kasus, AWS DMS mendukung pemrosesan perubahanCREATE,ALTER, dan DROP DDL pernyataan 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, tipe boolean data dalam SQL sumber Postgre dimigrasikan ke target SQL Server sebagai tipe bit data dengan nilai yang tidak konsisten. Sebagai solusinya, pra-buat tabel dengan tipe VARCHAR(1) data untuk kolom (atau AWS DMS buat tabel). Kemudian buatlah pemrosesan hilir memperlakukan “F” sebagai False dan “T” sebagai True.
AWS DMS tidak mendukung pemrosesan perubahan TRUNCATE operasi.
Tipe OID LOB data tidak dimigrasikan ke target.
AWS DMS mendukung tipe GIS data Post hanya untuk migrasi homogen.
Jika sumber Anda adalah SQL database Postgre yang ada di lokasi atau di EC2 instans Amazon, pastikan plugin keluaran test_decoding diinstal pada titik akhir sumber Anda. Anda dapat menemukan plugin ini di paket Postgre SQL contrib. Untuk informasi selengkapnya tentang plugin test-decoding, lihat dokumentasi Postgre. SQL
AWS DMS tidak mendukung pemrosesan perubahan untuk mengatur dan menghapus nilai default kolom (menggunakan ALTER COLUMN SET DEFAULT klausa pada ALTER TABLE pernyataan).
AWS DMS tidak mendukung pemrosesan perubahan untuk mengatur nullabilitas kolom (menggunakan NOT NULL klausa ALTER COLUMN [SET|DROP] 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, dan restart_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 Postgre SQL versi 13 dan yang lebih baru, Anda dapat menyetel logical_decoding_work_mem parameter untuk mengontrol saat DMS tumpahan mengubah data ke disk. Untuk informasi selengkapnya, lihat Memainkan file di Aurora Postgre SQL.
Tabel dengan tipe ARRAY data harus memiliki kunci utama. Tabel dengan tipe ARRAY data yang kehilangan kunci utama akan ditangguhkan selama pemuatan 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 yang dipartisi dari SQL sumber Postgre ke target Postgre, pertama-tama buat tabel induk dan anak secara manual pada SQL target. Kemudian tentukan tugas terpisah untuk mereplikasi ke tabel tersebut. Dalam kasus seperti itu, atur konfigurasi tugas Potong sebelum memuat.
Tipe SQL NUMERIC data Postgre tidak tetap dalam ukuran. Saat mentransfer data yang merupakan tipe NUMERIC data tetapi tanpa presisi dan skala, DMS gunakan NUMERIC(28,6) (presisi 28 dan skala 6) secara default. Sebagai contoh, nilai 0.611111104488373 dari sumber dikonversi ke 0.611111 pada target Postgre. SQL
AWS DMS mendukung Aurora Postgre SQL Serverless V1 sebagai sumber untuk tugas beban penuh saja. AWS DMS mendukung Aurora Postgre SQL Serverless V2 sebagai sumber untuk beban penuh, beban penuh dan, dan tugas -only. CDC CDC
AWS DMS tidak mendukung replikasi tabel dengan indeks unik yang dibuat dengan fungsi gabungan.
Saat menggunakan LOB mode, tabel sumber dan tabel target yang sesuai harus memiliki Kunci Utama yang identik. Jika salah satu tabel tidak memiliki Kunci Utama, hasil DELETE dan UPDATE catatan operasi 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 Postgre SQL 14.x sebagai sumber dengan batasan 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 Amazon RDS Proxy untuk Postgre SQL sebagai sumber.
Saat menggunakan filter sumber yang tidak berisi kolom Kunci Utama, DELETE operasi tidak akan ditangkap.
Jika basis data sumber Anda juga merupakan target untuk sistem replikasi pihak ketiga lainnya, DDL perubahan mungkin tidak akan 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 cluster database Amazon RDS Multi-AZ untuk Postgre SQL sebagai sumber, karena RDS untuk cluster database Postgre SQL multi-AZ tidak mendukung replikasi logis.

Tipe data sumber untuk Postgre SQL

Tabel berikut menunjukkan tipe data SQL sumber Postgre yang didukung saat menggunakan AWS DMS dan pemetaan default ke AWS DMS tipe data.

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.

Tipe data Postgre SQL	Tipe data DMS
INTEGER	INT4
SMALLINT	INT2
BIGINT	INT8
NUMERIC(p, s)	Jika presisi dari 0 hingga 38, maka gunakanNUMERIC. Jika presisi 39 atau lebih besar, maka gunakanSTRING.
DECIMAL(P, S)	Jika presisi dari 0 hingga 38, maka gunakanNUMERIC. Jika presisi 39 atau lebih besar, maka gunakanSTRING.
REAL	REAL4
DOUBLE	REAL8
SMALLSERIAL	INT2
SERIAL	INT4
BIGSERIAL	INT8
MONEY	NUMERIC(38,4) Tipe MONEY data dipetakan ke FLOAT dalam SQL Server.
CHAR	WSTRING(1)
CHAR(N)	WSTRING(n)
VARCHAR(N)	WSTRING(n)
TEXT	NCLOB
CITEXT	NCLOB
BYTEA	BLOB
TIMESTAMP	DATETIME
TIMESTAMP WITH TIME ZONE	DATETIME
DATE	DATE
TIME	TIME
TIME WITH TIME ZONE	TIME
INTERVAL	STRING(128) —1YEAR, 2MONTHS, 3DAYS, 4HOURS, 5MINUTES, 6 SECONDS
BOOLEAN	CHAR(5) salah atau benar
ENUM	STRING(64)
CIDR	STRING(50)
INET	STRING(50)
MACADDR	STRING(18)
BIT(n)	STRING(n)
BITVARYING(n)	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
INT4RANGE	STRING(255)
INT8RANGE	STRING(255)
NUMRANGE	STRING(255)
STRRANGE	STRING(255)

Bekerja dengan tipe data LOB sumber untuk Postgre SQL

Ukuran SQL kolom postgre mempengaruhi konversi tipe data Postgre ke tipe SQL LOB data. AWS DMS Untuk menggunakannya, ambil langkah-langkah berikut untuk jenis data AWS DMS berikut:

BLOB— Tetapkan LOBukuran Batas ke nilai LOBUkuran maksimum (KB) pada pembuatan tugas.
CLOB— Replikasi menangani setiap karakter sebagai UTF8 karakter. Oleh karena itu, temukan panjang teks karakter terpanjang di kolom, yang ditunjukkan di sini sebagaimax_num_chars_text. Gunakan panjang ini untuk menentukan nilai untuk Limit LOB size to. Jika data menyertakan karakter 4-byte, kalikan dengan 2 untuk menentukan Batas LOB ukuran ke nilai, yang dalam byte. Dalam hal ini, Batasi LOB ukuran untuk sama dengan max_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 Limit LOB size to. Dalam hal ini, Batasi LOB ukuran untuk sama dengan max_num_chars_text dikalikan dengan 2. Jika data memuat karakter 4-byte, kalikan dengan 2 lagi. Dalam hal ini, Batasi LOB ukuran untuk sama dengan max_num_chars_text dikalikan dengan 4.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Menggunakan Google Cloud untuk PostgreSQL sebagai sumber

Menggunakan My SQL sebagai sumber