Migrasi berkelanjutan (terkadang disebut sebagai migrasi yang sedang berlangsung atau online) adalah
aliran perubahan berkelanjutan dari database PostgreSQL sumber ke tujuan AlloyDB untuk PostgreSQL yang
mengikuti dump dan pemuatan penuh awal. Dalam kasus migrasi, saat
waktunya beralih untuk menggunakan tujuan untuk operasi baca dan tulis,
lakukan operasi promote. Promosi berarti instance tujuan terputus dari sumber, dan dipromosikan dari instance replika ke instance utama.
Migrasi berkelanjutan mengikuti langkah-langkah berikut:
Awalnya, snapshot diambil dari database sumber.
Tindakan ini akan menyebabkan penguncian singkat (di bawah 10 detik) pada tabel database, satu per
satu, saat dump dibuat. Sumber dapat terus menerima operasi tulis.
Setelah diambil, dump awal akan dimuat ke tujuan.
Setelah pemuatan selesai, perubahan yang sedang berlangsung (juga dikenal sebagai pengambilan data perubahan atau CDC) akan diproses.
Saat tiba waktunya untuk beralih menggunakan tujuan, berhentilah menulis ke
sumber dan mulai promosi. Hal ini memungkinkan aplikasi membaca dan
menulis ke database tujuan.
Aplikasi dependen dapat mengalami periode nonaktif setidaknya selama
durasi penundaan replikasi pada saat keputusan untuk melakukan promosi.
Migrasi satu kali
Jenis migrasi ini adalah snapshot database pada satu waktu tertentu,
yang diambil dari sumber dan diterapkan ke tujuan. Pada dasarnya, ini adalah dump
dan pemuatan, dengan tujuan siap
digunakan saat pemuatan selesai. Setiap aplikasi yang bergantung pada database sumber
dapat mengalami periode nonaktif selama proses migrasi karena tidak boleh ada operasi
penulisan baru ke database ini saat migrasi sedang berlangsung.
Migrasi satu kali mengikuti langkah-langkah berikut:
Hentikan penulisan ke database sumber.
Memulai dump database sumber.
Setelah selesai, dump akan dimuat ke tujuan. Setelah pemuatan selesai, promosi akan dimulai secara otomatis. Database
tujuan kini menjadi database utama, dan aplikasi dependen
harus membaca dan menulis ke database tersebut.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-05 UTC."],[[["\u003cp\u003eContinuous migration involves an initial snapshot of the source PostgreSQL database, followed by a continuous stream of changes to the AlloyDB destination, allowing for minimal downtime during the final switch.\u003c/p\u003e\n"],["\u003cp\u003eContinuous migration includes taking an initial database snapshot, loading it into the destination, processing ongoing changes, and finally promoting the destination to primary status.\u003c/p\u003e\n"],["\u003cp\u003eOne-time migration, which is currently unavailable for AlloyDB, involves a single snapshot of the source database and applying it to the destination, requiring a halt in writes to the source during the migration.\u003c/p\u003e\n"],["\u003cp\u003eReplication delay is the time between when a write occurs on the source and the current time, which will account for the downtime during a continuous migration switch.\u003c/p\u003e\n"]]],[],null,["# Types of migration\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/migration-types \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/migration-types \"View this page for the PostgreSQL version of Database Migration Service.\") \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\n### Continuous migration\n\nContinuous (sometimes referred to as ongoing or online) migration is a continuous flow of changes from a source PostgreSQL database to an AlloyDB for PostgreSQL destination that follows an initial full dump and load. In the case of a migration, when the time comes to switch to use the destination for reads and writes, perform a `promote` operation. Promotion means that the destination instance is disconnected from the source, and is promoted from a replica instance to a primary instance.\n\nContinuous migration follows these steps:\n\n1. Initially, a snapshot is taken of the source database.\n This incurs a short (under 10 seconds) lockout on the database tables, one at\n a time, as the dump is created. The source can continue accepting writes.\n\n \u003cbr /\u003e\n\n2. After the initial dump is taken, it's loaded into the destination.\n\n3. After the load is completed, the ongoing changes (also known as change data capture or CDC) are processed.\n\n | The delay between when a write occurs on the source and the current time is known as the `Replication delay`.\n\n \u003cbr /\u003e\n\n4. When the time comes to switch to using the destination, stop writing to the\n source and initiate a promotion. This allows the application to read and\n write against the destination database.\n\n5. Dependent applications can experience downtime for at least the\n duration of the replication delay at the time of the decision to promote.\n\n### One-time migration\n\n| One-time migration is currently not available for AlloyDB.\n\nThis type of migration is a single point-in-time snapshot of the database,\ntaken from the source and applied to the destination. This is essentially a dump\nand load, where the destination is ready to be\nused when the load completes. Any applications that depend on the source database\ncan experience downtime during the migration process because there can be no new\nwrites to this database while the migration is in progress.\n\nOne-time migration follows these steps:\n\n1. Stop writing to the source database.\n\n2. Initiate a dump of the source database.\n\n3. After the dump is complete, it's loaded into the destination. When the load\n is completed, a promotion is initiated automatically. The\n destination database now becomes the primary database, and dependent\n applications should read and write to it."]]
