Batasan umum

Sebelum Anda memilih untuk memigrasikan database ke AlloyDB untuk PostgreSQL, pertimbangkan batasan umum untuk skenario migrasi ini.

Batasan umum untuk menggunakan database PostgreSQL sebagai sumber meliputi:

  • Ekstensi pglogical tidak mendukung replikasi kolom yang dihasilkan untuk PostgreSQL 12+.

  • Perubahan pada struktur tabel (DDL) tidak direplikasi melalui perintah DDL standar, tetapi hanya dengan perintah yang dijalankan menggunakan ekstensi pglogical yang digunakan untuk replikasi. Hal ini mencakup perubahan pada jenis enum.

    • Misalnya, pglogical menyediakan fungsi pglogical.replicate_ddl_command yang memungkinkan DDL dijalankan di database sumber dan replika pada titik yang konsisten. Pengguna yang menjalankan perintah ini di sumber harus sudah ada di replika.
    • Untuk mereplikasi data untuk tabel yang baru dibuat, Anda harus menggunakan perintah pglogical.replication_set_add_table untuk menambahkan tabel baru ke set replikasi yang ada.
    • Untuk mempelajari lebih lanjut replikasi DDL saat migrasi sedang berlangsung, lihat Fidelitas migrasi.

  • Batasan objek:

    • Tabel asing tidak direplikasi oleh replikasi logis.
    • Tabel UNLOGGED dan TEMPORARY tidak dan tidak dapat direplikasi.
    • Jenis data Objek Besar (oid yang merujuk ke pg_largeobject) tidak didukung oleh decoding logis PostgreSQL.
    • Database Migration Service tidak memigrasikan data dari tampilan terwujud, hanya skema tampilan. Untuk mengisi tampilan di database tujuan, jalankan: REFRESH MATERIALIZED VIEW view_name;.
    • Status SEQUENCE (misalnya, last_value) di tujuan mungkin berbeda dengan sumber selama CDC berlangsung. Nilai urutan disinkronkan selama langkah promosi terakhir.

  • Untuk tabel yang tidak memiliki kunci utama, Database Migration Service mendukung migrasi snapshot awal dan pernyataan INSERT selama fase pengambilan data perubahan (CDC). Memigrasikan pernyataan UPDATE dan DELETE berbeda untuk:

    • Migrasi standar: Pernyataan UPDATE dan DELETE tidak dimigrasikan untuk tabel tanpa kunci utama. Anda harus menambahkan kunci utama untuk kolom sebelum bermigrasi, atau memigrasikan pernyataan UPDATE dan DELETE secara manual.
    • Migrasi mulai cepat: Dengan migrasi mulai cepat, kunci utama tidak diperlukan untuk mereplikasi operasi UPDATE dan DELETE jika Anda menetapkan identitas replika ke INDEX atau FULL. Mengonfigurasi REPLICA IDENTITY FULL akan meningkatkan volume write-ahead log (WAL) dan overhead resource. Sebaiknya tambahkan kunci utama jika memungkinkan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Identitas Replika PostgreSQL dan Panduan migrasi cepat.

  • Hanya ekstensi dan versi ekstensi yang didukung AlloyDB untuk PostgreSQL yang dapat dimigrasikan. Database Migration Service tidak memigrasikan ekstensi yang tidak didukung oleh AlloyDB untuk PostgreSQL, dan jika ada ekstensi di database sumber yang versinya tidak didukung oleh AlloyDB untuk PostgreSQL, pengujian atau memulai tugas migrasi mungkin akan gagal. Untuk memastikan migrasi berjalan lancar, pastikan ekstensi sumber Anda didukung dan aplikasi Anda tidak merujuk ke ekstensi yang tidak didukung. Untuk mengetahui daftar ekstensi yang didukung, lihat Ekstensi yang didukung dalam dokumentasi AlloyDB untuk PostgreSQL.

  • Ekstensi pg_cron (atau cron job apa pun yang dikonfigurasi dalam ekstensi) tidak dimigrasikan oleh Database Migration Service, tetapi didukung di tujuan AlloyDB untuk PostgreSQL. Jika Anda menggunakan pg_cron di database sumber, instal ulang ekstensi dan konfigurasikan cron job di cluster tujuan setelah migrasi selesai.

  • Database Migration Service tidak mendukung migrasi dari replika baca yang berada dalam mode pemulihan.

  • Database Migration Service tidak mendukung sumber Amazon RDS tempat paket ekstensi AWS SCT diterapkan.

  • Fungsi yang ditentukan pengguna yang ditulis dalam C tidak dapat dimigrasikan, kecuali untuk fungsi yang diinstal saat membuat ekstensi yang didukung oleh AlloyDB untuk PostgreSQL.

  • Database yang ditambahkan ke instance sumber setelah tugas migrasi dimulai tidak akan dimigrasikan.

  • Anda dapat memilih database tertentu saat melakukan migrasi menggunakan Database Migration Service. Semua tabel dan skema dari database yang dipilih akan dimigrasikan, kecuali:

    • Skema informasi (information_schema).
    • Setiap skema yang diawali dengan pg_ (misalnya, pg_catalog, pg_toast, pgtemp*). Untuk daftar lengkap katalog PostgreSQL yang diawali dengan pg_, lihat katalog sistem PostgreSQL dalam dokumentasi PostgreSQL.
    • Kredensial login dan peran pengguna.

  • Jika database terenkripsi memerlukan kunci enkripsi yang dikelola pelanggan (CMEK) untuk mendekripsi data, dan Database Migration Service tidak memiliki akses ke kunci tersebut, database tidak dapat dimigrasikan. Namun, data yang dienkripsi dengan ekstensi pgcrypto dapat dimigrasikan karena AlloyDB untuk PostgreSQL mendukung pgcrypto. Database Migration Service juga mendukung migrasi dari database Amazon Aurora atau Amazon RDS yang dienkripsi karena AWS menangani dekripsi secara transparan. Untuk mengetahui informasi selengkapnya, lihat Mengenkripsi resource Amazon Aurora dan Mengenkripsi resource Amazon RDS.

  • Database yang dimigrasikan tidak dilindungi dari penulisan selama migrasi: AlloyDB untuk PostgreSQL tidak menjalankan instance tujuan dalam mode hanya baca selama migrasi. Meskipun Anda dapat terhubung ke cluster tujuan untuk membuat dan mengelola pengguna database atau menerapkan perubahan skema yang diperlukan (DDL), jangan lakukan operasi tulis (seperti INSERT, UPDATE, atau DELETE) pada database atau tabel yang sedang dimigrasikan. Menulis ke data yang sedang dimigrasikan dapat menyebabkan konflik replikasi atau kegagalan migrasi.

  • Perilaku pemicu bergantung pada konfigurasi pemicu. Secara default, pemicu tidak diaktifkan pada replika selama replikasi, kecuali jika dikonfigurasi dengan ALTER EVENT TRIGGER atau ALTER TABLE ... ENABLE ALWAYS TRIGGER.

  • Tablespace kustom dipetakan ke tablespace pg_default default di AlloyDB untuk PostgreSQL.

  • Metode konektivitas antarmuka Private Service Connect hanya didukung untuk migrasi ke cluster tujuan yang ada. Jika Anda ingin menggunakan konektivitas IP pribadi dan bermigrasi ke cluster tujuan baru dalam migrasi standar, gunakan peering VPC.

  • Autentikasi database Identity and Access Management untuk cluster tujuan tidak didukung. Database Migration Service terhubung ke database tujuan menggunakan autentikasi pengguna database. Untuk mengetahui informasi selengkapnya tentang IAM, lihat Mengelola autentikasi IAM dalam dokumentasi AlloyDB untuk PostgreSQL.

Fungsi pendefinisi keamanan

Fungsi yang ditentukan dengan SECURITY DEFINER berjalan dengan hak istimewa pengguna yang memiliki fungsi tersebut, bukan pengguna yang menjalankannya.

Selama migrasi berkelanjutan ke AlloyDB untuk PostgreSQL, rutinitas yang ditentukan dengan SECURITY DEFINER akan dimiliki oleh pengguna layanan migrasi internal alloydbexternalsync di instance utama tujuan. Karena alloydbexternalsync memiliki hak istimewa administratif yang ditingkatkan, termasuk peran alloydbsuperuser dan alloydbreplica, setiap pengguna yang diizinkan untuk menjalankan fungsi ini akan menjalankannya dengan hak alloydbsuperuser penuh. Hal ini menimbulkan risiko eskalasi hak istimewa yang tidak diinginkan.

Untuk mengatasi risiko ini, audit semua fungsi SECURITY DEFINER di cluster tujuan Anda dan cabut hak istimewa eksekusi publik segera setelah migrasi:

REVOKE EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) TO "AUTHORIZED_USER";

Penyelarasan pemeriksaan dan lokalitas

AlloyDB untuk PostgreSQL ditetapkan secara default ke lokalitas C.UTF-8 dan en_US.utf8 yang disediakan oleh libc. Semua lokalitas lainnya di AlloyDB untuk PostgreSQL menggunakan kolasi International Components for Unicode (ICU).

Jika database sumber Anda menggunakan pemeriksaan default berdasarkan lokalitas libc lain, default tersebut tidak akan otomatis diterapkan. Untuk memastikan pengurutan yang konsisten untuk kueri yang menggunakan ORDER BY, Anda mungkin perlu mengupdate tabel dengan pemeriksaan ICU eksplisit setelah migrasi. Untuk mengetahui informasi selengkapnya, lihat Lokalitas yang didukung untuk data yang diimpor dalam dokumentasi AlloyDB untuk PostgreSQL.

Batasan untuk migrasi ke cluster tujuan yang ada

  • Anda hanya dapat mengonfigurasi satu tugas migrasi aktif per cluster tujuan.
  • Penurunan cluster tujuan untuk migrasi standar: Untuk migrasi standar ke cluster AlloyDB untuk PostgreSQL yang ada, Database Migration Service menurunkan cluster mandiri untuk mengonfigurasinya sebagai replika eksternal database sumber.
    • Anda harus mengonfirmasi penurunan versi saat membuat tugas migrasi di konsol Google Cloud dengan memasukkan ID cluster tujuan (atau dengan menjalankan gcloud database-migration migration-jobs demote-destination).
    • Migrasi mulai cepat menggunakan replikasi logis PostgreSQL pgnative dan tidak memerlukan atau melakukan penurunan versi cluster tujuan.
  • Untuk migrasi standar, cluster tujuan yang ada harus kosong atau hanya berisi data konfigurasi sistem default. Migrasi ke cluster tujuan yang sudah ada dan berisi data pengguna (seperti tabel) tidak didukung untuk migrasi standar.

    Jika Anda mengalami masalah karena data tambahan di cluster tujuan yang ada, hapus database di cluster tujuan dan coba lagi tugas migrasi. Lihat Menghapus data tambahan dari cluster tujuan yang ada.

  • Migrasi ke cluster dengan instance kumpulan baca didukung. Untuk mengetahui informasi selengkapnya tentang cluster dan instance AlloyDB untuk PostgreSQL, lihat Ringkasan AlloyDB untuk PostgreSQL.

Pertimbangan paralelisme dump data

Saat membuat tugas migrasi, Anda dapat meningkatkan jumlah langganan paralel untuk mempercepat dump data awal dan replikasi change data capture (CDC) yang sedang berlangsung. Menggunakan setelan paralelisme dump data yang lebih tinggi juga akan meningkatkan pemakaian koneksi dan resource di database sumber dan cluster AlloyDB untuk PostgreSQL tujuan.

  • Pastikan database sumber Anda memiliki CPU, memori, dan headroom I/O yang memadai sebelum Anda menggunakan paralelisme Maksimum.
  • Saat menggunakan paralelisme dump data yang disesuaikan, Anda harus mengonfigurasi nilai yang lebih tinggi untuk max_replication_slots, max_wal_senders, dan max_worker_processes di database sumber. Untuk penghitungan parameter yang mendetail, lihat Mengonfigurasi database sumber.
  • Ekstensi pglogical mereplikasi data di tingkat tabel selama dump penuh awal. Satu tabel yang tidak dipartisi ditetapkan ke satu langganan dan tidak dibagi ke beberapa langganan paralel atau thread pekerja.
  • Ekstensi pglogical mereplikasi partisi leaf satu per satu sebagai tabel terpisah dan dapat mendistribusikan beberapa partisi leaf di seluruh langganan paralel selama dump penuh awal. Satu partisi leaf yang besar tidak dapat dibagi ke beberapa langganan dan disalin oleh satu thread.
  • Database Migration Service mengurutkan tabel berdasarkan ukuran dan mendistribusikannya di seluruh langganan paralel. Database Migration Service membuat hingga 2 langganan per database (dan total hingga 2 langganan di semua database) untuk paralelisme Optimal, dan hingga 4 langganan per database (dan total hingga 4 langganan di semua database) untuk paralelisme Maksimum, dengan setidaknya 1 langganan per database yang dimigrasikan. Misalnya, jika database memiliki satu tabel berukuran 1 TB dan beberapa tabel kecil, Database Migration Service akan mengisolasi tabel berukuran 1 TB dalam satu langganan dan mendistribusikan tabel yang lebih kecil ke langganan yang tersisa. Meskipun beberapa langganan aktif, kecepatan dump awal secara keseluruhan masih dibatasi oleh waktu yang diperlukan untuk menyalin satu tabel berukuran 1 TB.
  • Database Migration Service menetapkan tabel tanpa kunci utama ke set replikasi khusus sisipkan saja (satu per langganan paralel). Beberapa tabel tanpa kunci utama dapat didistribusikan di seluruh langganan paralel, tetapi selama dump penuh awal, setiap tabel disalin sebagai aliran tabel tunggal dalam satu langganan dan tidak dibagi di beberapa thread paralel.

Kuota

  • Hingga 2.000 profil koneksi dan 1.000 tugas migrasi dapat ada kapan saja. Untuk mengosongkan ruang, hapus tugas migrasi dan profil koneksi yang tidak digunakan. Untuk mengetahui detail selengkapnya, lihat Kuota dan batas.

Kompatibilitas versi ekstensi PostgreSQL selama upgrade versi utama

Saat Anda bermigrasi ke versi utama PostgreSQL yang lebih tinggi, Database Migration Service menggunakan utilitas pg_restore, yang menginstal versi ekstensi default dari versi utama PostgreSQL target. Anda tidak dapat menentukan versi ekstensi yang tepat untuk utilitas pg_restore.

Jika database sumber Anda menggunakan versi ekstensi yang skemanya tidak kompatibel dengan versi default yang diinstal pada versi utama PostgreSQL target, migrasi mungkin gagal karena ketidakcocokan skema atau error internal.

Untuk menghindari kegagalan migrasi, verifikasi kompatibilitas skema. Sebelum melakukan migrasi, upgrade ekstensi di database sumber ke versi yang kompatibel dengan versi utama PostgreSQL target.

Langkah berikutnya