Menggunakan basis data PostgreSQL sebagai sumber AWS DMS

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 lokal

• Basis data 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.

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 basis data dapat berupa basis data 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.

  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 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 instance 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 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 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

1. 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.

2. 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 parameter wal_level, max_wal_senders, max_replication_slots, dan max_connections. Perubahan parameter ini dapat meningkatkan generasi write ahead log (WAL), jadi atur rds.logical_replication saja ketika Anda menggunakan slot replikasi logis.

3. 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.

4. 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.

5. 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

1. Pilih skema di tempat objek akan dibuat. Skema default adalah public. Pastikan bahwa skema ada dan dapat diakses oleh akun OtherThanMaster.

2. Masuk ke instans DB PostgreSQL menggunakan akun pengguna selain akun master, berikut akun OtherThanMaster.

3. 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
   );
                              
                           

4. 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;
   $$;
                           

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

6. 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();
                           

7. 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

1. Buat ekstensi pglogical pada basis data PostgreSQL sumber Anda:

   1. 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 menjadi pglogical dalam grup parameter RDS yang sama.

   2. Mulai ulang basis data sumber PostgreSQL Anda.

   3. Pada basis data PostgreSQL, jalankan perintah, create extension pglogical;

2. 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, PluginNameuntuk 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 (ECA) 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

1. 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.

2. Buat titik akhir sumber baru yang mencakup pengaturan atribut sambungan tambahan berikut.

   slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;

3. 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 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 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

1. Buat slot replikasi, seperti yang ditunjukkan berikut:

   SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical');
                       

2. 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

3. Buat node pglogical.

   SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name');
                       

4. 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);

5. 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);
                       

6. 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 3.7

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 memigrasi data dari basis data sumber PostgreSQL yang berjalan pada EC2 ke target Amazon 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

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 (ECA) 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 spesifik, hal itu dilakukan untuk WALs yang mengidentifikasi baris yang diperbarui atau dihapus. REPLICA IDENTITY FULL mencatat nilai-nilai lama dari semua kolom di baris. Gunakan REPLICA IDENTITY FULL dengan hati-hati untuk setiap table seraya FULLmenghasilkan sejumlah tambahan WALs yang mungkin tidak diperlukan. Untuk informasi lebih lanjut, lihat ALTER TABLE-REPLICA IDENTITY

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 (ECA) saat menggunakan PostgreSQL sebagai sumber DMS

Anda dapat menggunakan pengaturan titik akhir dan atribut koneksi tambahan (ECA) 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 '{"EndpointSetting": "value", ...}' JSON.

Tabel berikut menunjukkan pengaturan endpoint dan ECA yang dapat Anda gunakan dengan PostgreSQL sebagai sumber.

Nama atribut	Deskripsi
CaptureDDLs	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: true Nilai yang benar: benar/salah Contoh: --postgre-sql-settings '{"CaptureDDLs": true}'
ConsumeMonotonicEvents	Digunakan untuk mengontrol bagaimana transaksi monolitik dengan Log Sequence Numbers (LSNs) duplikat direplikasi. Bila parameter ini false, peristiwa dengan LSNs duplikat dikonsumsi dan direplikasi pada target. Bila parameter ini true, hanya peristiwa pertama yang direplikasi sementara peristiwa dengan LSNs duplikat 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 basis data DL operasional dibuat. Nilai default: publik Nilai yang benar: String Contoh: --postgre-sql-settings '{"DdlArtifactsSchema": "xyzddlschema"}'
ExecuteTimeout	Menetapkan pernyataan timeout klien untuk instans PostgreSQL, dalam hitungan detik. Nilai default adalah 60 detik. Contoh: --postgre-sql-settings '{"ExecuteTimeout": 100}'
FailTasksOnLobTruncation	Ketika diatur menjadi true, nilai ini menyebabkan tugas gagal jika ukuran kolom LOB sebenarnya lebih besar dari yang LobMaxSize tentukan. 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: --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 Contoh ECA: fetchCacheSize=10000;
HeartbeatFrequency	Menetapkan frekuensi WAL heartbeat (dalam 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 memetakan JSONB ke NCLOB. Anda dapat menentukan MapJsonbAsClob untuk membiarkan PostgreSQL memigrasikan tipe JSONB sebagai CLOB. Contoh: --postgre-sql-settings='{"MapJsonbAsClob": "true"}'
MapLongVarcharAs	Secara default, AWS DMS memetakan VARCHAR ke WSTRING. Anda dapat menentukan MapLongVarcharAs untuk membiarkan PostgreSQL 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 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: 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 versi yang lebih tinggi catatan Hanya gunakan MapUnboundedNumericAsString di sumber PostgreSQL dan titik akhir target bersama-sama. Penggunaan titik akhir PostgreSQL sumber membatasi presisi hingga 28 selama CDC. MapUnboundedNumericAsString 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 beban CDC dari instans sumber PostgreSQL. Saat digunakan dengan parameter CdcStartPosition permintaan AWS DMS API, atribut ini juga memungkinkan penggunaan titik awal CDC asli. DMS melakukan verifikasi bahwa slot replikasi logis tertentu ada sebelum memulai tugas beban CDC. Hal ini juga memverifikasi bahwa tugas dibuat dengan pengaturan CdcStartPosition yang valid. Jika slot yang ditentukan tidak ada atau tugas tidak memiliki pengaturan CdcStartPosition yang valid, DMS memunculkan kesalahan. Untuk informasi selengkapnya tentang pengaturan parameter permintaan CdcStartPosition, lihat Menentukan titik awal CDC asli. Untuk informasi lebih lanjut tentang penggunaan CdcStartPosition, lihat dokumentasi untuk operasi API CreateReplicationTask, StartReplicationTask, dan ModifyReplicationTask diAWS Database Migration Service Referensi API . Nilai yang benar: 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 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 Mulai Perubahan Proses dari 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, TABEL1, dan Tabel1) dapat menyebabkan perilaku tak 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 data bit dengan nilai-nilai yang tidak konsisten. Sebagai solusinya, pra-buat tabel dengan tipe VARCHAR(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 basis data PostgreSQL yang lokal atau pada instans Amazon EC2, pastikan bahwa plugin output 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, 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 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 data NUMERIC tetapi tanpa presisi dan skala, DMS menggunakan NUMERIC(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.

• Saat menggunakan mode LOB, tabel sumber dan tabel target yang sesuai harus memiliki Kunci Utama yang identik. Jika salah satu tabel tidak memiliki Kunci Utama, hasil operasi catatan DELETE dan UPDATE tidak akan 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
INT4RANGE	STRING (255)
INT8RANGE	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 karakter UTF8. 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 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.