Ringkasan peningkatan instance ApsaraDB RDS for PostgreSQL ke kluster PolarDB for PostgreSQL - PolarDB

Anda dapat meningkatkan instance ApsaraDB RDS for PostgreSQL ke PolarDB for PostgreSQL. Topik ini menjelaskan proses peningkatan, metode yang tersedia, manfaat, prasyarat, batasan, serta aturan penagihan.

Tentang peningkatan

PolarDB memungkinkan Anda meningkatkan instance ApsaraDB RDS for PostgreSQL ke PolarDB for PostgreSQL. Kluster tujuan PolarDB menggunakan akun, database, dan daftar putih alamat IP dari instance ApsaraDB RDS for PostgreSQL sumber.

Anda dapat meningkatkan instance ApsaraDB RDS for PostgreSQL ke kluster PolarDB for PostgreSQL yang menjalankan versi PostgreSQL yang sama atau berbeda. Sebagai contoh, Anda dapat meningkatkan instance ApsaraDB RDS for PostgreSQL 11 ke kluster PolarDB for PostgreSQL 14.

Catatan

Anda dapat menggunakan Data Transmission Service (DTS) untuk melakukan migrasi logis saat meningkatkan instance ApsaraDB RDS for PostgreSQL ke PolarDB for PostgreSQL.

Migrasi logis

Buat tugas sinkronisasi data di konsol DTS untuk memigrasikan skema dan data penuh dari instance ApsaraDB RDS for PostgreSQL sumber ke kluster tujuan PolarDB for PostgreSQL. Pastikan bahwa data inkremental disinkronkan ke kluster tujuan.

Manfaat

Peningkatan ini memberikan manfaat sebagai berikut:

Peningkatan mendukung pergantian dengan titik akhir. Aplikasi Anda dapat terhubung secara mulus ke kluster tujuan PolarDB tanpa mengubah pengaturan koneksi.
Migrasi ini gratis. Anda hanya dikenakan biaya untuk kluster tujuan PolarDB.
Tidak ada kehilangan data selama migrasi.
Migrasi data inkremental didukung. Waktu henti layanan tidak lebih dari 10 menit.
Migrasi panas didukung. Hanya satu pemutusan sementara yang terjadi selama proses migrasi data, yaitu ketika bisnis dialihkan dari instance ApsaraDB RDS for PostgreSQL ke kluster PolarDB.
Pembatalan migrasi didukung. Jika migrasi gagal, migrasi dapat dibatalkan dalam waktu 10 menit.

Prasyarat

Versi instance ApsaraDB RDS for PostgreSQL sumber harus lebih awal atau sama dengan kluster tujuan PolarDB for PostgreSQL.
Jika trigger dibuat di instance ApsaraDB RDS for PostgreSQL sumber, hapus trigger tersebut lalu klik Lanjutkan. Atau, Anda dapat membuat tugas sinkronisasi data secara manual di konsol DTS. Untuk informasi lebih lanjut, lihat Sinkronkan data dari instance ApsaraDB RDS for PostgreSQL ke kluster PolarDB for PostgreSQL.
Jika Secure Sockets Layer (SSL) atau enkripsi data transparan (TDE) diaktifkan untuk titik akhir instance ApsaraDB RDS for PostgreSQL sumber, Anda tidak dapat meningkatkan instance tersebut ke kluster PolarDB.
Instance ApsaraDB RDS for PostgreSQL sumber juga harus memenuhi kondisi berikut untuk peningkatan. Jika suatu kondisi tidak terpenuhi, kondisi tersebut akan ditampilkan di halaman peningkatan PolarDB.
- Database harus dibuat di instance ApsaraDB RDS for PostgreSQL.
- Nama akun instance ApsaraDB RDS for PostgreSQL tidak boleh menggunakan format yang tidak didukung oleh kluster PolarDB for PostgreSQL.
- Peran layanan terkait AliyunServiceRoleForPolarDB harus dibuat.
- Nilai parameter max_replication_slots harus lebih besar dari jumlah total link DTS dua arah yang diperlukan, seperti yang ditunjukkan oleh jumlah database yang terlibat.
- Nilai parameter max_wal_senders harus lebih besar dari jumlah total link DTS dua arah yang diperlukan, seperti yang ditunjukkan oleh jumlah database yang terlibat.
- Jumlah database harus kurang dari atau sama dengan 30. Anda dapat membuat hingga 30 link DTS dua arah.
- Nilai parameter kernel wal_level harus logis.

Batasan

Anda hanya dapat meningkatkan instance ApsaraDB RDS for PostgreSQL ke kluster PolarDB for PostgreSQL versi yang sama atau versi yang lebih baru. Penurunan versi tidak didukung. Sebagai contoh, Anda tidak dapat meningkatkan instance ApsaraDB RDS for PostgreSQL 14 ke kluster PolarDB for PostgreSQL 11.
Tugas migrasi secara otomatis membuat akun di kluster tujuan PolarDB dengan nama dalam format dts_clone%. Kata sandinya dihasilkan secara acak. Jangan ubah kata sandi atau hapus akun selama migrasi. Anda dapat mengubah kata sandi atau menghapus akun setelah migrasi selesai.

Peningkatan ini tunduk pada batasan berikut:

Migrasi data lintas wilayah tidak didukung.
Anda tidak dapat mengonfigurasi parameter instance ApsaraDB RDS for PostgreSQL sumber selama migrasi data.

Instance ApsaraDB RDS for PostgreSQL sumber tunduk pada batasan yang dijelaskan dalam tabel berikut.

Item

Deskripsi

Batasan pada instance sumber

Tabel yang ingin Anda sinkronkan harus memiliki PRIMARY KEY atau batasan UNIQUE, dan semua bidang harus unik. Jika tidak, database tujuan mungkin berisi catatan data duplikat.
Jika Anda memilih tabel sebagai objek yang akan disinkronkan dan Anda ingin memodifikasi tabel, seperti mengganti nama tabel atau kolom di database tujuan, Anda dapat menyinkronkan hingga 5.000 tabel dalam satu tugas sinkronisasi data. Jika Anda menjalankan tugas untuk menyinkronkan lebih dari 5.000 tabel, kesalahan permintaan terjadi. Dalam kasus ini, kami sarankan Anda mengonfigurasi beberapa tugas untuk menyinkronkan tabel atau mengonfigurasi tugas untuk menyinkronkan seluruh database.
Persyaratan berikut untuk log write-ahead logging (WAL) harus dipenuhi:
- Parameter wal_level harus diatur ke logical.
- Jika Anda hanya melakukan sinkronisasi data inkremental, log WAL dari database sumber harus disimpan selama lebih dari 24 jam. Jika Anda melakukan sinkronisasi data penuh dan sinkronisasi data inkremental, log WAL dari database sumber harus disimpan setidaknya selama tujuh hari. Jika tidak, DTS mungkin gagal mendapatkan log WAL dan tugas mungkin gagal. Dalam kasus khusus, ketidaksesuaian data atau kehilangan data mungkin terjadi. Setelah sinkronisasi data penuh selesai, Anda dapat mengatur periode retensi menjadi lebih dari 24 jam. Pastikan Anda menentukan periode retensi log WAL berdasarkan persyaratan di atas. Jika tidak, keandalan layanan atau kinerja dalam Service Level Agreement (SLA) DTS mungkin tidak dijamin.
Selama sinkronisasi data, jangan modifikasi titik akhir atau zona instance ApsaraDB RDS for PostgreSQL. Jika tidak, tugas sinkronisasi data gagal.
Jika database sumber memiliki transaksi jangka panjang dan data inkremental disinkronkan dalam tugas sinkronisasi data, log WAL yang dihasilkan sebelum transaksi jangka panjang di database sumber dikomit mungkin terakumulasi. Akibatnya, ruang disk database sumber mungkin menjadi tidak mencukupi.

Batasan pada pernyataan SQL:

Tipe	Pernyataan SQL
DML	INSERT, UPDATE, dan DELETE
DDL	Jika Anda menggunakan akun istimewa untuk instance ApsaraDB RDS for PostgreSQL dan instance tersebut menjalankan versi mesin minor 20210228 atau lebih baru, Anda dapat menyinkronkan pernyataan DDL berikut. Untuk informasi tentang cara memperbarui versi mesin minor, lihat Perbarui versi mesin minor. CREATE TABLE and DROP TABLE ALTER TABLE (termasuk RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, dan ALTER COLUMN DROP DEFAULT) TRUNCATE TABLE (database sumber menjalankan PostgreSQL 11 atau lebih baru) CREATE INDEX ON TABLE Penting Anda tidak dapat menyinkronkan informasi tambahan dalam pernyataan DDL, seperti CASCADE atau RESTRICT. Anda tidak dapat menyinkronkan pernyataan DDL dari sesi yang mengeksekusi pernyataan `SET session_replication_role = replica`. Jika beberapa pernyataan SQL yang dikomit oleh database sumber pada saat yang sama berisi pernyataan DML dan DDL, DTS tidak menyinkronkan pernyataan DDL. Jika beberapa pernyataan SQL yang dikomit oleh database sumber pada saat yang sama berisi pernyataan DDL untuk objek yang tidak disinkronkan, pernyataan DDL tersebut tidak disinkronkan.

Batasan lainnya:

Item

Deskripsi

Batasan lainnya

Setiap tugas sinkronisasi data hanya dapat menyinkronkan satu database. Untuk beberapa database, tugas sinkronisasi data terpisah dikonfigurasi untuk setiap database.
Jika Anda membuat tabel di skema atau mengeksekusi pernyataan RENAME untuk membuat ulang tabel selama sinkronisasi tingkat skema, Anda harus mengeksekusi pernyataan ALTER TABLE schema.table REPLICA IDENTITY FULL; sebelum Anda menulis data ke tabel untuk memastikan konsistensi data. Saat mengeksekusi pernyataan ini, kami sarankan Anda tidak mengunci tabel. Jika tidak, deadlock terjadi.
Catatan
- Ganti skema dan tabel dalam pernyataan di atas dengan nama skema dan nama tabel aktual saat Anda melakukan operasi.
- Kami sarankan Anda melakukan operasi selama jam-jam sepi.
DTS membuat tabel sementara berikut di database sumber untuk mendapatkan pernyataan DDL dari data inkremental, skema tabel inkremental, dan informasi denyut jantung. Selama sinkronisasi data, jangan hapus tabel sementara di database sumber. Jika tidak, pengecualian terjadi. Setelah instance DTS dilepaskan, tabel sementara secara otomatis dihapus.
public.dts_pg_class, public.dts_pg_attribute, public.dts_pg_type, public.dts_pg_enum, public.dts_postgres_heartbeat, public.dts_ddl_command, dan public.dts_args_session.
Untuk memastikan bahwa latensi sinkronisasi data akurat, DTS menambahkan tabel denyut jantung bernama dts_postgres_heartbeat ke database sumber.
Selama sinkronisasi data, DTS membuat slot replikasi di database sumber untuk mereplikasi data. Slot replikasi diawali dengan dts_sync_. DTS secara otomatis membersihkan slot replikasi historis setiap 120 menit untuk mengurangi penggunaan penyimpanan.
Catatan
- DTS secara otomatis menghapus slot replikasi setelah instance dilepaskan. Jika Anda mengubah kata sandi database atau menghapus daftar putih alamat IP DTS selama sinkronisasi, slot replikasi tidak dapat dihapus secara otomatis. Dalam kasus ini, Anda harus secara manual menghapus slot replikasi dari database sumber. Jika Anda tidak menghapus slot replikasi, slot replikasi terus mengakumulasi penggunaan penyimpanan. Ini dapat mengakibatkan instance ApsaraDB RDS for PostgreSQL tidak tersedia.
- Jika tugas sinkronisasi data dilepaskan atau gagal, DTS secara otomatis membersihkan slot replikasi. Jika switchover utama/sekunder dilakukan di database sumber PostgreSQL, Anda harus masuk ke database sekunder untuk membersihkan slot replikasi.
Sebelum Anda menyinkronkan data, evaluasi dampak sinkronisasi data pada kinerja database sumber dan tujuan. Kami sarankan Anda menyinkronkan data selama jam-jam sepi. Selama sinkronisasi data penuh awal, DTS menggunakan sumber daya baca dan tulis database sumber dan tujuan. Ini dapat meningkatkan beban pada server database.
Selama sinkronisasi data penuh, operasi INSERT konkuren menyebabkan fragmentasi di tabel database tujuan. Setelah sinkronisasi data penuh selesai, ruang tabel database tujuan lebih besar daripada database sumber.
Untuk sinkronisasi data tingkat tabel, jika data ditulis ke database tujuan hanya menggunakan DTS, Anda dapat menggunakan Data Management (DMS) untuk melakukan operasi DDL tanpa kunci. Untuk informasi lebih lanjut, lihat Lakukan operasi DDL tanpa kunci.
Selama sinkronisasi data, kami sarankan Anda hanya menggunakan DTS untuk menulis data ke tujuan. Ini mencegah ketidaksesuaian data antara database sumber dan tujuan. Sebagai contoh, jika Anda menggunakan alat selain DTS untuk menulis data ke database tujuan, kehilangan data mungkin terjadi di database tujuan ketika Anda menggunakan DMS untuk melakukan operasi DDL online.
DTS tidak memeriksa validitas metadata seperti urutan. Anda harus secara manual memeriksa validitas metadata.
Setelah beban kerja Anda dialihkan ke database tujuan, urutan baru tidak bertambah dari nilai maksimum urutan di database sumber. Oleh karena itu, Anda harus memeriksa nilai maksimum urutan di database sumber sebelum Anda mengalihkan beban kerja Anda ke database tujuan. Kemudian, Anda harus menentukan nilai maksimum yang diperiksa sebagai nilai awal urutan di database tujuan. Anda dapat mengeksekusi pernyataan berikut untuk memeriksa nilai maksimum urutan di database sumber:
```
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;
$$;
```

Aturan penagihan

Aturan penagihan berikut berlaku untuk peningkatan:

Anda dikenakan biaya untuk kluster PolarDB dan tugas sinkronisasi data di DTS. Namun, fitur peningkatan berada dalam fase uji coba gratis. Tidak ada biaya yang dihasilkan untuk tugas sinkronisasi dalam 30 hari setelah tugas dibuat. Tabel berikut menjelaskan aturan penagihan.

Tipe sinkronisasi

Aturan penagihan

Sinkronisasi skema dan sinkronisasi data penuh

Tidak ada biaya yang dihasilkan untuk tugas sinkronisasi dalam 30 hari setelah tugas dibuat.

Setelah 30 hari, tugas dibatalkan. Tidak ada biaya yang dihasilkan.

Catatan

Anda dapat masuk ke konsol PolarDB dan melihat periode validitas tersisa dari tugas sinkronisasi di bagian RDS Migration halaman Basic Information.

Sinkronisasi data inkremental

Pergantian dengan titik akhir (tidak diperlukan perubahan koneksi)

Ketika Anda meningkatkan instance ApsaraDB RDS for PostgreSQL ke kluster PolarDB, Anda dapat memilih Pergantian dengan Titik Akhir (Tidak Diperlukan Perubahan Koneksi). Kemudian, sistem menukar titik akhir antara instance ApsaraDB RDS for PostgreSQL dan kluster PolarDB. Dalam hal ini, Anda tidak perlu memodifikasi konfigurasi aplikasi Anda untuk terhubung ke kluster PolarDB. Gambar berikut menunjukkan aturan untuk menukar titik akhir antara instance RDS dan kluster PolarDB.

Untuk pergantian dengan titik akhir, perhatikan poin-poin berikut:

Hanya titik akhir instance ApsaraDB RDS for PostgreSQL dan kluster PolarDB yang ditukar. Konfigurasi lainnya seperti vSwitch dan alamat IP virtual tidak ditukar.
Titik akhir hanya dapat ditukar jika instance ApsaraDB RDS for PostgreSQL sumber dan kluster tujuan PolarDB memiliki titik akhir. Secara default, hanya titik akhir utama di jaringan internal yang dapat ditukar.
Titik akhir utama instance ApsaraDB RDS for PostgreSQL dan kluster PolarDB ditukar selama pergantian dengan titik akhir. Anda dapat memilih apakah akan menukar titik akhir proxy khusus instance ApsaraDB RDS for PostgreSQL dengan titik akhir kluster default kluster PolarDB, dan titik akhir hanya-baca instance ApsaraDB RDS for PostgreSQL dengan titik akhir kustom kluster PolarDB berdasarkan kebutuhan bisnis Anda. Kluster PolarDB dapat memiliki hingga tujuh titik akhir kluster. Oleh karena itu, hingga tujuh titik akhir proxy khusus atau titik akhir hanya-baca instance ApsaraDB RDS for PostgreSQL dapat ditukar dengan titik akhir kluster kluster PolarDB.
Jika Anda ingin menggunakan titik akhir lainnya, buat titik akhir tersebut sebelum pergantian. Untuk informasi tentang cara membuat titik akhir untuk kluster PolarDB, lihat Lihat atau ajukan permohonan titik akhir. Untuk informasi lebih lanjut tentang cara membuat titik akhir untuk instance ApsaraDB RDS for PostgreSQL, lihat Konfigurasi titik akhir untuk instance RDS.
Port tidak ditukar antara instance ApsaraDB RDS for PostgreSQL dan kluster PolarDB selama pergantian dengan titik akhir. Pastikan bahwa port instance ApsaraDB RDS for PostgreSQL sama dengan port kluster PolarDB kecuali untuk port titik akhir kustom. Untuk informasi tentang cara memodifikasi port, lihat Lihat dan kelola titik akhir dan port instance.
Setelah titik akhir ditukar, masalah mungkin terjadi karena kedaluwarsa data cache Domain Name System (DNS). Database di kluster PolarDB mungkin gagal terhubung atau hanya mendukung operasi baca. Kami sarankan Anda menyegarkan data cache DNS server Anda untuk memperbaiki masalah ini.
Jika Anda ingin menggunakan DMS untuk masuk ke database PolarDB setelah titik akhir ditukar, gunakan versi terbaru DMS dan ID kluster untuk masuk ke database.