Data Transmission Service:Migrasi data dari database PostgreSQL yang dikelola sendiri ke AnalyticDB for PostgreSQL

Persyaratan database sumber

• Server sumber harus memiliki bandwidth keluar yang mencukupi. Bandwidth rendah mengurangi kecepatan migrasi.

• Tabel harus memiliki kendala PRIMARY KEY atau UNIQUE, dan semua field harus unik. Tabel tanpa kendala ini dapat menghasilkan catatan duplikat di tujuan.

• Nama database sumber tidak boleh mengandung tanda hubung (-). Misalnya, dts-testdata bukan nama yang valid.

• Jika Anda memilih tabel sebagai objek migrasi dan perlu mengganti nama tabel atau kolom di tujuan, satu tugas migrasi mendukung maksimal 1.000 tabel. Untuk migrasi yang lebih besar, bagi menjadi beberapa tugas atau migrasikan pada tingkat database.

• Migrasi inkremental memerlukan parameter wal_level diatur ke logical di database sumber.

• Retensi write-ahead log (WAL):

  • Hanya migrasi data inkremental: simpan log WAL selama lebih dari 24 jam.

  • Migrasi data penuh + migrasi data inkremental: simpan log WAL selama minimal 7 hari.

  • Setelah migrasi penuh selesai, Anda dapat mengurangi periode retensi menjadi lebih dari 24 jam. Retensi yang tidak mencukupi dapat menyebabkan DTS gagal membaca log WAL, sehingga tugas gagal atau terjadi kehilangan data.

• Selama migrasi, hindari operasi berikut pada database sumber:

  • Alih bencana primer/sekunder — ini akan menyebabkan tugas migrasi gagal.

  • Operasi DDL selama migrasi data penuh — ini akan menyebabkan tugas migrasi gagal.

  • Menulis data ke sumber selama migrasi hanya penuh — ini menyebabkan inkonsistensi data. Untuk menghindari risiko ini, sertakan migrasi data inkremental dalam tugas Anda.

• Transaksi jangka panjang dengan write-ahead log terbuka dapat menumpuk dan menghabiskan ruang disk di sumber saat migrasi inkremental berjalan.

Persyaratan database tujuan

• Selama migrasi data penuh dan migrasi data inkremental, DTS secara sementara menonaktifkan pemeriksaan kendala dan operasi kaskade pada kunci asing di tingkat sesi. Jika Anda melakukan operasi pembaruan atau penghapusan kaskade pada database sumber selama migrasi, inkonsistensi data dapat terjadi.

• Tabel tujuan tidak boleh merupakan tabel append-optimized (AO).

• DTS tidak memigrasikan jenis objek berikut: DATATYPE, SEQUENCE, INDEX, PROCEDURE, FUNCTION, VIEW, OPERATOR, DEFAULT_CONSTRAINT, UK, PK, RULE, DOMAIN, AGGREGATE, EXTENSION, FK, dan TRIGGER.

• Jika Anda menggunakan pemetaan kolom untuk migrasi tabel parsial, data di kolom sumber yang tidak memiliki kolom tujuan yang sesuai akan hilang.

• Untuk tabel dengan kunci primer: kolom kunci primer di tujuan harus sesuai dengan yang ada di sumber.

• Untuk tabel tanpa kunci primer: kolom kunci primer dan kunci distribusi di tujuan harus sama.

• Kunci unik di tujuan harus mencakup semua kolom kunci distribusinya (termasuk kolom kunci primer).

• DTS tidak mendukung migrasi tabel ekstensi TimescaleDB atau tabel dengan relasi pewarisan lintas-skema.

• DTS tidak mendukung migrasi tabel partisi kecuali Anda menyertakan tabel induk dan semua tabel anak sebagai objek migrasi. Tabel induk tidak menyimpan data — semua data berada di tabel anak.

Perilaku migrasi inkremental

REPLICA IDENTITY dan replikasi UPDATE/DELETE

PostgreSQL menggunakan REPLICA IDENTITY untuk mengontrol seberapa banyak data kolom yang ditulis ke dalam catatan WAL untuk event UPDATE dan DELETE. Pengaturan default (DEFAULT) hanya menyertakan kolom kunci primer dalam catatan tersebut. Saat DTS mereplikasi operasi UPDATE atau DELETE, DTS memerlukan nilai sebelumnya dari semua kolom untuk mengidentifikasi dan menerapkan perubahan secara akurat di tujuan. Tanpa identitas FULL, DTS tidak dapat mereplikasi event UPDATE atau DELETE secara andal, yang dapat menyebabkan inkonsistensi data.

Jika tugas migrasi Anda mencakup migrasi data inkremental, jalankan perintah berikut pada setiap tabel yang akan dimigrasikan sebelum menulis data ke dalamnya. Ini mengatur REPLICA IDENTITY ke FULL, yang mencatat semua nilai kolom untuk event UPDATE dan DELETE:

ALTER TABLE schema.table REPLICA IDENTITY FULL;

Ganti schema dan table dengan nama skema dan nama tabel yang sebenarnya. Jalankan perintah ini selama jam sepi dan hindari penguncian tabel saat dieksekusi.

Jalankan perintah ini dalam situasi berikut:

• Saat instans DTS pertama kali dijalankan.

• Saat granularitas objek migrasi adalah Skema, dan Anda membuat tabel baru atau membangun ulang tabel menggunakan perintah RENAME di skema yang sedang dimigrasikan.

Jika Anda melewati item pemeriksaan awal terkait, DTS secara otomatis menjalankan perintah ini selama inisialisasi instans.

Tabel temporary dan slot replikasi

DTS membuat tabel temporary berikut di database sumber. Jangan menghapusnya selama migrasi — tugas dapat gagal jika tabel tersebut dihapus. DTS menghapusnya secara otomatis setelah instans dilepas.

public.dts_pg_class, public.dts_pg_attribute, public.dts_pg_type, public.dts_pg_enum, public.dts_postgres_heartbeat, public.dts_ddl_command, public.dts_args_session, public.aliyun_dts_instance

Tabel dts_postgres_heartbeat adalah tabel heartbeat yang digunakan DTS untuk memastikan akurasi latensi migrasi inkremental.

DTS juga membuat slot replikasi dengan awalan dts_sync_ dan membersihkan data historisnya setiap 90 menit untuk mengurangi penggunaan penyimpanan. Jika tugas migrasi dilepas atau gagal, DTS secara otomatis membersihkan slot replikasi tersebut. Jika alih bencana primer/sekunder dilakukan pada instans ApsaraDB RDS for PostgreSQL, login ke database sekunder dan bersihkan slot replikasi secara manual.

Catatan migrasi inkremental lainnya

• Untuk menggunakan tugas migrasi data yang dibuat sebelum 12 Mei 2023 guna memigrasikan operasi DDL, Anda harus membuat pemicu dan fungsi di database sumber untuk menangkap informasi DDL sebelum mengonfigurasi tugas migrasi data. Untuk informasi lebih lanjut, lihat Gunakan pemicu dan fungsi untuk menerapkan migrasi DDL inkremental untuk database PostgreSQL.

• Migrasi data inkremental tidak mendukung kolom dengan tipe data BIT.

• Saat DTS menulis pernyataan UPDATE ke instans AnalyticDB for PostgreSQL tujuan, DTS secara otomatis mengonversinya menjadi REPLACE INTO. Jika UPDATE menargetkan kolom kunci primer, DTS mengonversinya menjadi DELETE + INSERT.

• DTS mendukung replikasi DDL hanya untuk tugas yang dibuat setelah 1 Oktober 2020. Untuk tugas yang dibuat sebelum 12 Mei 2023, buat pemicu dan fungsi di database sumber untuk menangkap DDL sebelum mengonfigurasi tugas. Lihat Gunakan pemicu dan fungsi untuk menerapkan migrasi DDL inkremental untuk database PostgreSQL.

• Akun database yang digunakan untuk migrasi inkremental harus memiliki izin superuser untuk mereplikasi DDL. Operasi DDL yang didukung:

  • CREATE TABLE, DROP TABLE

  • ALTER TABLE: RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, ALTER COLUMN DROP DEFAULT

  • TRUNCATE TABLE (memerlukan PostgreSQL V11 atau lebih baru di sumber)

  • CREATE INDEX ON TABLE

• DTS tidak mereplikasi: DDL dengan CASCADE atau RESTRICT, DDL dari sesi yang menjalankan SET session_replication_role = replica, DDL yang dieksekusi melalui panggilan fungsi, CREATE SEQUENCE, atau batch yang mencampur DML dan DDL.

Catatan lainnya

• Satu tugas migrasi mencakup satu database. Buat tugas terpisah untuk setiap database tambahan.

• Sebelum memigrasikan data, evaluasi dampaknya terhadap kinerja database sumber dan tujuan. Kami menyarankan Anda memigrasikan data selama jam sepi. Selama migrasi data penuh, DTS menggunakan sumber daya baca dan tulis kedua database, yang dapat meningkatkan beban pada server database.

• Migrasi data penuh menggunakan operasi INSERT konkuren, yang menyebabkan fragmentasi pada tabel tujuan. Setelah migrasi, ruang tabel tujuan lebih besar daripada sumber.

• DTS menggunakan ROUND(COLUMN, PRECISION) untuk membaca kolom FLOAT dan DOUBLE. Presisi default: 38 digit untuk FLOAT, 308 digit untuk DOUBLE. Verifikasi apakah ini memenuhi kebutuhan presisi Anda sebelum migrasi.

• DTS mencoba melanjutkan tugas yang gagal hingga 7 days. Sebelum mengalihkan beban kerja ke tujuan, hentikan atau lepaskan tugas yang gagal, atau jalankan REVOKE untuk mencabut izin tulis DTS dari tujuan. Jika tugas yang gagal dilanjutkan setelah Anda beralih, data di tujuan akan ditimpa.

• DTS tidak memvalidasi metadata sequence. Periksa validitas sequence secara manual.

• Setelah beralih ke tujuan, sequence baru tidak dimulai dari nilai maksimum di sumber. Sebelum beralih, kueri nilai sequence sumber dan atur sebagai nilai awal di tujuan:

  do language plpgsql $$
  declare
    nsp name;
    rel name;
    val int8;
  begin
    for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
    loop
      execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
      raise notice '%',
      format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
    end loop;
  end;
  $$;

  Output berisi pernyataan setval untuk semua sequence di sumber. Jalankan hanya pernyataan yang berlaku untuk objek migrasi Anda di tujuan.

• Jika instans DTS gagal, helpdesk mencoba memulihkannya dalam waktu 8 jam. Pemulihan dapat mencakup restart instans atau penyesuaian parameter instans DTS (bukan parameter database). Untuk parameter yang dapat disesuaikan, lihat Ubah parameter instans.

PostgreSQL 10.1 atau lebih baru

1. Login ke server yang menjalankan database PostgreSQL yang dikelola sendiri.

2. Buka postgresql.conf dan perbarui parameter berikut: Contoh konfigurasi:

   • Atur wal_level ke logical.

   • Atur max_wal_senders dan max_replication_slots ke nilai yang lebih besar dari jumlah: slot replikasi yang sedang digunakan di sumber, ditambah jumlah instans DTS yang menggunakan database sumber ini.

   # - Settings -
   
   wal_level = logical			# minimal, replica, or logical
   					# (change requires restart)
   
   ......
   
   # - Sending Server(s) -
   
   # Set these on the master and on any standby that will send replication data.
   
   max_wal_senders = 10		# max number of walsender processes
   				# (change requires restart)
   #wal_keep_segments = 0		# in logfile segments, 16MB each; 0 disables
   #wal_sender_timeout = 60s	# in milliseconds; 0 disables
   
   max_replication_slots = 10	# max number of replication slots
   				# (change requires restart)

   Restart database untuk menerapkan perubahan.

3. Tambahkan Blok CIDR server DTS ke pg_hba.conf. Tambahkan hanya Blok CIDR untuk server DTS di wilayah yang sama dengan database tujuan. Untuk daftar Blok CIDR, lihat Tambahkan alamat IP server DTS ke daftar putih. Setelah mengedit pg_hba.conf, jalankan SELECT pg_reload_conf(); atau restart database untuk menerapkan perubahan. Lewati langkah ini jika alamat IP di pg_hba.conf sudah diatur ke 0.0.0.0/0.

   

4. Buat database dan skema yang sesuai di instans AnalyticDB for PostgreSQL tujuan.

PostgreSQL 9.4.8 hingga 10.0

Versi PostgreSQL di bawah 10.1 memerlukan plug-in ali_decoding untuk mendukung replikasi logis. Ikuti langkah-langkah berikut untuk mengompilasi dan menginstalnya.

1. Unduh kode sumber PostgreSQL yang sesuai dengan versi database Anda dari situs resmi PostgreSQL.

2. Kompilasi dan instal PostgreSQL dengan menjalankan perintah berikut secara berurutan:

   Penting

   - Versi OS harus kompatibel dengan versi GNU Compiler Collection (GCC). - Jika sudo ./configure gagal karena error readline, jalankan sudo ./configure --without-readline sebagai gantinya. - Jika Anda menginstal PostgreSQL dengan metode lain, kompilasi plug-in ali_decoding di Lingkungan pengujian dengan versi OS dan GCC yang sama.

   sudo ./configure
   sudo make
   sudo make install

3. Unduh plug-in ali_decoding.

4. Salin direktori ali_decoding ke direktori contrib dari instalasi PostgreSQL yang telah dikompilasi.

   

5. Ganti isi Makefile di direktori ali_decoding dengan berikut ini:

   # contrib/ali_decoding/Makefile
   MODULE_big = ali_decoding
   MODULES = ali_decoding
   OBJS    = ali_decoding.o
   
   DATA = ali_decoding--0.0.1.sql ali_decoding--unpackaged--0.0.1.sql
   
   EXTENSION = ali_decoding
   
   NAME = ali_decoding
   
   #subdir = contrib/ali_decoding
   #top_builddir = ../..
   #include $(top_builddir)/src/Makefile.global
   #include $(top_srcdir)/contrib/contrib-global.mk
   
   #PG_CONFIG = /usr/pgsql-9.6/bin/pg_config
   #pgsql_lib_dir := $(shell $(PG_CONFIG) --libdir)
   #PGXS := $(shell $(PG_CONFIG) --pgxs)
   #include $(PGXS)
   
   # Run the following commands to install the ali_decoding plug-in:
   ifdef USE_PGXS
   PG_CONFIG = pg_config
   PGXS := $(shell $(PG_CONFIG) --pgxs)
   include $(PGXS)
   else
   subdir = contrib/ali_decoding
   top_builddir = ../..
   include $(top_builddir)/src/Makefile.global
   include $(top_srcdir)/contrib/contrib-global.mk
   endif

6. Dari direktori ali_decoding, jalankan perintah berikut secara berurutan untuk mengompilasi dan menginstal plug-in:

   sudo make
   sudo make install

7. Salin file yang telah dikompilasi ke direktori yang diperlukan.

   

8. Buat database dan skema yang sesuai di instans AnalyticDB for PostgreSQL tujuan.

Langkah 1: Buka halaman Data Migration

Gunakan Konsol DTS atau Konsol DMS.

Langkah 2: Konfigurasi database sumber dan tujuan

Klik Create Task, lalu konfigurasikan parameter berikut.

Database sumber

Database tujuan

Langkah 3: Uji konektivitas

Klik Test Connectivity and Proceed.

DTS memerlukan akses ke kedua database. Pastikan Blok CIDR server DTS telah ditambahkan ke pengaturan keamanan kedua database. Lihat Tambahkan alamat IP server DTS ke daftar putih.

Jika sumber atau tujuan adalah database yang dikelola sendiri yang tidak diakses sebagai Alibaba Cloud Instance, klik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers.

Langkah 4: Konfigurasi objek migrasi

Jenis migrasi dan objek

Parameter	Deskripsi
Migration types	Pilih Schema Migration dan Full Data Migration untuk migrasi satu kali. Untuk menjaga sumber tetap online selama migrasi, pilih juga Incremental Data Migration. Jika Anda melewatkan Schema Migration, buat database dan tabel tujuan secara manual dan aktifkan pemetaan nama objek di Selected Objects.
Processing mode of conflicting tables	Precheck and Report Errors: pemeriksaan awal gagal jika ada tabel tujuan yang memiliki nama sama dengan tabel sumber. Gunakan pemetaan nama objek untuk menyelesaikan konflik. Ignore Errors and Proceed: melewati pemeriksaan konflik nama, tetapi berisiko menyebabkan inkonsistensi data — selama migrasi penuh, catatan yang bertabrakan tetap disimpan di tujuan; selama migrasi inkremental, catatan tersebut ditimpa.
DDL and DML operations to be synchronized	Pilih operasi SQL yang akan direplikasi selama migrasi inkremental. Lihat Perilaku migrasi inkremental untuk operasi yang didukung. Untuk mengonfigurasi di tingkat database atau tabel, klik kanan objek di Selected objects dan pilih operasi tersebut.
Storage engine type	Default: Beam. Tersedia hanya jika versi minor AnalyticDB for PostgreSQL tujuan adalah v7.0.6.6 atau lebih baru dan Schema Migration dipilih.
Capitalization of object names in destination instance	Mengontrol kapitalisasi nama database, tabel, dan kolom di tujuan. Default: DTS default policy. Lihat Tentukan kapitalisasi nama objek di instans tujuan.
Source objects	Pilih objek yang akan dimigrasikan dan klik untuk menambahkannya ke Selected objects. Anda dapat memilih kolom, tabel, atau skema. Memilih tabel atau kolom mengecualikan view, trigger, dan stored procedure.
Selected objects	Untuk mengganti nama satu objek, klik kanan objek tersebut. Untuk mengganti nama beberapa objek sekaligus, klik Batch Edit. Lihat Pemetaan nama objek. Untuk memfilter baris, klik kanan tabel dan atur kondisi WHERE. Lihat Atur kondisi filter.

Langkah 5: Konfigurasi pengaturan lanjutan

Klik Next: Advanced Settings dan konfigurasikan parameter berikut.

Langkah 6: Konfigurasi verifikasi data (opsional)

Klik Next Step: Data Verification. Untuk petunjuk penyiapan, lihat Konfigurasi tugas verifikasi data.

Langkah 7: Konfigurasi kolom kunci primer dan distribusi

Klik Next: Configure Database and Table Fields untuk mengatur kolom kunci primer dan distribusi untuk tabel yang dimigrasikan di instans AnalyticDB for PostgreSQL tujuan.

Halaman ini hanya muncul jika Schema Migration dipilih. Untuk informasi lebih lanjut tentang kolom kunci primer dan kolom distribusi, lihat Manajemen Tabel Data dan Definisi Distribusi Tabel.

Langkah 8: Jalankan pemeriksaan awal

Klik Next: Save Task Settings and Precheck.

Untuk melihat pratinjau parameter API untuk konfigurasi ini, arahkan kursor ke Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters.

DTS menjalankan pemeriksaan awal sebelum memulai migrasi. Anda hanya dapat memulai tugas setelah lulus pemeriksaan awal.

Jika pemeriksaan awal gagal, klik View Details di samping setiap item yang gagal, perbaiki masalahnya, lalu klik Precheck Again.

Jika muncul peringatan untuk suatu item:

• Jika peringatan tidak dapat diabaikan, klik View Details, perbaiki masalahnya, lalu jalankan pemeriksaan awal lagi.

• Jika peringatan dapat diabaikan, klik Confirm Alert Details > Ignore > OK, lalu klik Precheck Again.

Langkah 9: Beli dan mulai instans

1. Tunggu hingga Success Rate mencapai 100%, lalu klik Next: Purchase Instance.

2. Di halaman Purchase Instance, konfigurasikan:

   Parameter	Deskripsi
   Resource group	Kelompok sumber daya untuk instans migrasi. Default: default resource group.
   Instance class	Pilih kelas instans berdasarkan kecepatan migrasi yang dibutuhkan. Lihat Kelas instans migrasi data.

3. Baca dan terima Data Transmission Service (Pay-as-you-go) Service Terms.

4. Klik Buy and Start, lalu klik OK di dialog konfirmasi.

Lacak progres di halaman Data Migration.

Tugas migrasi skema + migrasi data penuh berhenti otomatis saat selesai. Status menunjukkan Completed.

Tugas migrasi data inkremental berjalan terus-menerus. Status menunjukkan Running. Hentikan tugas secara manual saat Anda siap mengalihkan beban kerja ke tujuan.