(Pratinjau) Migrasi secara online, dari server Google AlloyDB for PostgreSQL ke Azure Database for PostgreSQL, dengan layanan migrasi

Artikel ini memandu Anda dalam memigrasikan instans PostgreSQL dari komputer virtual (VM) lokal atau Azure Anda ke Azure Database for PostgreSQL dalam mode online.

Layanan migrasi di Azure Database for PostgreSQL adalah layanan terkelola penuh yang terintegrasi ke portal Microsoft Azure dan Azure CLI. Ini menyederhanakan perjalanan migrasi Anda ke server fleksibel Azure Database for PostgreSQL.

• Prasyarat
• Lakukan migrasi
• Memantau migrasi
• Memulai alih fungsi
• Periksa migrasi saat selesai

Prasyarat

Untuk memulai migrasi, Anda memerlukan prasyarat berikut:

Sebelum memulai migrasi dengan layanan migrasi Azure Database for PostgreSQL, penting untuk memenuhi prasyarat berikut, yang dirancang khusus untuk skenario migrasi online.

• Memverifikasi versi sumber
• Menginstal test_decoding - Penyiapan Sumber
• Mengonfigurasi penyiapan target
• Mengaktifkan CDC sebagai sumber
• Mengonfigurasi penyiapan jaringan
• Mengaktifkan ekstensi
• Periksa parameter server
• Memeriksa pengguna dan peran

Memverifikasi versi sumber

Versi server PostgreSQL sumber harus 9.5 atau yang lebih baru.

Jika versi PostgreSQL sumber kurang dari 9,5, tingkatkan ke 9,5 atau lebih tinggi sebelum Anda memulai migrasi.

Nota

Layanan migrasi di Azure Database for PostgreSQL mendukung koneksi menggunakan alamat IP untuk Sumber Google AlloyDB for PostgreSQL. Format myproject:myregion:myinstance tidak didukung.

Menginstal test_decoding - pengaturan sumber

• test_decoding menerima WAL melalui mekanisme decoding logis dan mendekodekannya ke dalam representasi teks dari operasi yang dilakukan.
• Di Google AlloyDB for PostgreSQL, plugin test_decoding telah diinstal sebelumnya dan siap untuk replikasi logis. Ini memungkinkan Anda untuk dengan mudah menyiapkan slot replikasi logis dan mentransmisikan perubahan WAL, memfasilitasi kasus penggunaan seperti penangkapan data perubahan (CDC) atau replikasi ke sistem eksternal.
• Untuk informasi selengkapnya tentang plugin test-decoding, lihat dokumentasi PostgreSQL

Mengonfigurasi pengaturan target

• Sebelum bermigrasi, Azure Database for PostgreSQL – Server fleksibel harus dibuat.
• SKU yang disediakan untuk Azure Database for PostgreSQL – Server Fleksibel harus sesuai dengan sumber aslinya.
• Untuk membuat Azure Database for PostgreSQL baru, kunjungi Membuat server fleksibel Azure Database for PostgreSQL

Mengaktifkan CDC sebagai sumber

• test_decoding plugin dekoding logika menangkap catatan yang telah diubah dari sumbernya.
• Untuk memastikan pengguna migrasi memiliki hak istimewa replikasi yang diperlukan, jalankan perintah SQL berikut:

ALTER USER <user> WITH REPLICATION;

• Buka instans Google AlloyDB PostgreSQL di Google Cloud Console, pilih nama instans untuk membuka halaman detailnya, pilih tombol Edit, dan di bagian Bendera, ubah bendera berikut:

  • Atur bendera alloydb.logical_decoding = on
  • Atur bendera max_replication_slots ke nilai yang lebih besar dari satu; nilainya harus lebih besar dari jumlah database yang dipilih untuk migrasi.
  • Atur bendera max_wal_senders ke nilai yang lebih besar dari satu. Setidaknya harus sama dengan max_replication_slots, ditambah jumlah pengirim yang sudah digunakan pada instance Anda.
  • Bendera wal_sender_timeout mengakhiri koneksi replikasi tidak aktif lebih lama dari jumlah milidetik yang ditentukan. Mengatur nilai ke 0 (nol) menonaktifkan mekanisme batas waktu dan merupakan pengaturan yang valid untuk migrasi.

• Di server fleksibel target, untuk mencegah migrasi Online kehabisan ruang penyimpanan untuk menyimpan log, pastikan Anda memiliki ruang tabel yang cukup menggunakan disk terkelola yang sudah disediakan. Untuk mencapai hal ini, nonaktifkan parameter azure.enable_temp_tablespaces_on_local_ssd server selama durasi migrasi, dan pulihkan ke status asli setelah migrasi.

Mengonfigurasi penyiapan jaringan

Penyiapan jaringan sangat penting agar layanan migrasi berfungsi dengan benar. Pastikan server PostgreSQL sumber dapat berkomunikasi dengan server Azure Database for PostgreSQL target. Konfigurasi jaringan berikut sangat penting untuk keberhasilan migrasi.

Untuk informasi tentang penyiapan jaringan, kunjungi Panduan jaringan untuk layanan migrasi.

Mengaktifkan ekstensi

Untuk memastikan keberhasilan migrasi dengan menggunakan layanan migrasi di Azure Database for PostgreSQL, Anda mungkin perlu memverifikasi ekstensi ke instans PostgreSQL sumber Anda. Ekstensi menyediakan fungsionalitas dan fitur yang mungkin diperlukan untuk aplikasi Anda. Pastikan Anda memverifikasi ekstensi pada instans PostgreSQL sumber sebelum memulai proses migrasi.

Pada server fleksibel Azure Database untuk PostgreSQL pada instans target, aktifkan ekstensi yang didukung dan teridentifikasi di instans PostgreSQL sumber.

Untuk informasi selengkapnya, lihat Ekstensi dan modul.

Periksa parameter server

Parameter ini tidak secara otomatis dimigrasikan ke lingkungan target dan harus dikonfigurasi secara manual.

• Cocokkan nilai parameter server dari database PostgreSQL sumber ke Azure Database for PostgreSQL dengan mengakses bagian "Parameter server" di portal Azure dan memperbarui nilai secara manual.

• Simpan perubahan parameter dan mulai ulang Azure Database for PostgreSQL untuk menerapkan konfigurasi baru jika perlu.

Memeriksa pengguna dan peran

Saat bermigrasi ke Azure Database for PostgreSQL, penting untuk mengatasi migrasi pengguna dan peran secara terpisah, karena mereka memerlukan intervensi manual:

• Migrasi manual pengguna dan peran: Pengguna dan peran terkait mereka harus dimigrasikan secara manual ke Azure Database for PostgreSQL. Untuk memfasilitasi proses ini, Anda dapat menggunakan utilitas pg_dumpall dengan flag --globals-only guna mengekspor objek global seperti role dan akun pengguna. Jalankan perintah berikut, ganti <<username>> dengan nama pengguna yang sebenarnya dan <<filename>> dengan nama file output yang Anda inginkan:

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

• Pembatasan peran superuser: Azure Database for PostgreSQL tidak mendukung peran superuser. Oleh karena itu, hak istimewa superuser harus dicabut dari pengguna sebelum migrasi. Pastikan Anda menyesuaikan izin dan peran secara sesuai.

Dengan mengikuti langkah-langkah ini, Anda dapat memastikan bahwa akun dan peran pengguna dimigrasikan dengan benar ke Azure Database for PostgreSQL tanpa mengalami masalah yang terkait dengan pembatasan superuser.

Nonaktifkan ketersediaan tinggi (keandalan) dan replika baca pada target

• Menonaktifkan ketersediaan tinggi (keandalan) dan membaca replika di lingkungan target sangat penting. Fitur-fitur ini harus diaktifkan hanya setelah migrasi selesai.

• Dengan mengikuti panduan ini, Anda dapat membantu memastikan proses migrasi lancar tanpa variabel tambahan yang diperkenalkan oleh HA dan Read Replicas. Setelah migrasi selesai dan database stabil, Anda dapat melanjutkan untuk mengaktifkan fitur-fitur ini untuk meningkatkan ketersediaan dan skalabilitas lingkungan database Anda di Azure.

Lakukan migrasi

Anda dapat bermigrasi dengan menggunakan portal Microsoft Azure atau Azure CLI.

Portal

Artikel ini memandu Anda menggunakan portal Microsoft Azure untuk memigrasikan database PostgreSQL Anda dari server Google AlloyDB for PostgreSQL ke Azure Database for PostgreSQL. Portal Microsoft Azure memungkinkan Anda melakukan berbagai tugas, termasuk migrasi database. Dengan mengikuti langkah-langkah yang diuraikan dalam tutorial ini, Anda dapat mentransfer database Anda dengan mulus ke Azure dan memanfaatkan fitur dan skalabilitasnya yang canggih.

Mengonfigurasi tugas migrasi

Layanan migrasi dilengkapi dengan pengalaman sederhana berbasis wizard di portal Microsoft Azure.

Menggunakan portal Microsoft Azure:

1. Pilih Azure Database untuk server fleksibel PostgreSQL Anda.

2. Di menu sumber daya, pilih Migrasi.

   

3. Pilih Buat untuk menelusuri serangkaian tab berbasis wizard untuk melakukan migrasi ke server fleksibel dari lokal atau Azure VM.

   Nota

   Pertama kali Anda menggunakan layanan migrasi, sebuah grid kosong akan ditampilkan dengan petunjuk untuk memulai migrasi pertama Anda.

   Jika migrasi ke server tujuan fleksibel Anda telah dibuat, tabel sekarang berisi informasi tentang migrasi yang telah diupayakan.

   

Pengaturan

Anda perlu memberikan beberapa detail yang terkait dengan migrasi, seperti nama migrasi, jenis server sumber, opsi, dan mode.

• Nama migrasi adalah pengidentifikasi unik untuk setiap migrasi ke target server fleksibel ini. Bidang ini hanya menerima karakter alfanumerik dan tidak menerima karakter khusus apa pun kecuali tanda hubung (-). Nama tidak boleh diawali dengan tanda hubung dan harus unik untuk server target. Tidak ada dua migrasi ke target server fleksibel yang sama yang dapat memiliki nama yang sama.

• Jenis server sumber - Bergantung pada sumber PostgreSQL, Anda dapat memilih Azure Virtual Machine atau Server lokal.

• Opsi migrasi - Memungkinkan Anda melakukan validasi sebelum memicu migrasi. Anda dapat memilih salah satu opsi berikut:

  • Validasi - Memeriksa kesiapan server dan database Anda untuk migrasi ke target.
  • Validasi dan migrasi — Melakukan validasi sebelum memicu migrasi. Jika tidak ada kegagalan validasi, migrasi dimulai.

Memilih opsi Validasi atau Validasi dan migrasi selalu merupakan praktik yang baik untuk melakukan validasi pramigrasi sebelum menjalankan migrasi.

Untuk mempelajari lebih lanjut soal validasi pramigrasi, kunjungi pramigrasi.

• Mode migrasi memungkinkan Anda memilih mode untuk migrasi. Offline adalah opsi default. Dalam hal ini, kita akan mengubahnya menjadi Online.

Pilih Berikutnya: Server runtime.

Server runtime

Server runtime migrasi adalah fitur khusus dalam layanan migrasi di Azure Database for PostgreSQL, yang dirancang untuk bertindak sebagai server perantara selama migrasi. Ini adalah instans server fleksibel Azure Database for PostgreSQL terpisah yang bukan server target, tetapi digunakan untuk memfasilitasi migrasi database dari lingkungan sumber yang hanya dapat diakses melalui jaringan privat.

Untuk informasi selengkapnya tentang server runtime, kunjungi Server runtime migrasi.

Server sumber

Tab Server sumber meminta Anda untuk memberikan detail yang terkait dengan sumber yang dipilih di tab Penyetelan , yang merupakan sumber database.

• Nama server - Berikan nama host atau alamat IP server PostgreSQL sumber.
• Port - Nomor port server sumber.
• Login administrator - Nama pengguna administrator server PostgreSQL sumber.
• Kata sandi - Kata sandi login administrator yang disediakan untuk terhubung ke server PostgreSQL sumber.
• Mode SSL - Nilai yang didukung adalah preferred dan required. Ketika SSL di server PostgreSQL sumber adalah OFF, gunakan prefer. Jika SSL di server sumber adalah ON, gunakan require. Nilai SSL dapat ditentukan dalam file postgresql.conf dari server sumber.
• Uji koneksi — Melakukan pengujian konektivitas antara target dan sumber. Setelah koneksi berhasil, Anda dapat melanjutkan ke tab berikutnya. Pengujian ini bertujuan untuk mengidentifikasi masalah konektivitas apa pun yang mungkin ada antara server target dan sumber, termasuk verifikasi autentikasi menggunakan kredensial yang disediakan. Membuat koneksi pengujian membutuhkan waktu beberapa detik.

Setelah koneksi pengujian berhasil, pilih Berikutnya: Server target.

Server target

Tab Server target menampilkan metadata untuk target server fleksibel, seperti nama langganan, grup sumber daya, nama server, lokasi, dan versi PostgreSQL.

• Login administrator - Nama pengguna administrator server PostgreSQL target.
• Kata sandi - Kata sandi login administrator yang disediakan untuk terhubung ke server PostgreSQL target.
• FQDN kustom atau alamat IP: Bidang FQDN atau alamat IP kustom bersifat opsional, dan dapat digunakan ketika target berada di belakang server DNS kustom atau memiliki namespace DNS kustom, membuatnya hanya dapat diakses melalui FQDN atau alamat IP tertentu. Misalnya, ini dapat mencakup entri seperti production-flexible-server.example.com, 198.1.0.2, atau PostgreSQL FQDN seperti production-flexible-server.postgres.database.azure.com, jika DNS server kustom berisi zona DNS postgres.database.azure.com atau meneruskan kueri untuk zona ini ke 168.63.129.16, di mana FQDN diselesaikan di zona DNS publik atau privat Azure.
• Uji koneksi — Melakukan pengujian konektivitas antara sumber dan target. Setelah koneksi berhasil, Anda dapat melanjutkan ke tab berikutnya. Pengujian ini bertujuan untuk mengidentifikasi masalah konektivitas apa pun yang mungkin ada antara server sumber dan target, termasuk verifikasi autentikasi menggunakan kredensial yang disediakan. Membuat koneksi pengujian membutuhkan waktu beberapa detik.

Setelah koneksi pengujian berhasil, pilih Berikutnya: Database untuk memvalidasi atau memigrasikan

Database untuk memvalidasi atau memigrasikan

Di bawah tab Database untuk memvalidasi atau memigrasikan , Anda bisa memilih daftar database pengguna untuk dimigrasikan dari server PostgreSQL sumber Anda.

Setelah memilih database, pilih Berikutnya: Ringkasan.

Ringkasan

Tab Ringkasan meringkas semua detail sumber dan target untuk membuat validasi atau migrasi. Tinjau detail dan pilih Mulai validasi dan migrasi.

Membatalkan validasi atau migrasi

Anda dapat membatalkan validasi atau migrasi yang sedang berlangsung. Alur kerja harus dalam status Sedang berlangsung untuk dibatalkan. Anda tidak dapat membatalkan validasi atau migrasi dalam status Berhasil atau Gagal .

Membatalkan validasi akan menghentikan aktivitas validasi lebih lanjut dan validasi berpindah ke status Dibatalkan .

Membatalkan migrasi menghentikan aktivitas migrasi lebih lanjut di server target Anda dan pindah ke status Dibatalkan . Ini tidak menghilangkan atau mengembalikan perubahan apa pun di server target Anda. Pastikan untuk menghilangkan database di server target Anda yang terlibat dalam migrasi yang dibatalkan.

CLI

Artikel ini menjelajahi menggunakan Azure CLI untuk memigrasikan database PostgreSQL Anda dari komputer virtual Azure atau instans PostgreSQL lokal ke Azure Database for PostgreSQL. Azure CLI menyediakan antarmuka baris perintah yang kuat dan fleksibel yang memungkinkan Anda melakukan berbagai tugas, termasuk migrasi database. Mengikuti langkah-langkah yang diuraikan dalam artikel ini, Anda dapat mentransfer database Anda dengan mulus ke Azure dan memanfaatkan fitur dan skalabilitasnya yang canggih.

Untuk mempelajari selengkapnya tentang Azure CLI dengan layanan migrasi, kunjungi Cara menyiapkan Azure CLI untuk layanan migrasi.

Setelah CLI diinstal, buka prompt perintah dan masuk ke akun Azure Anda menggunakan perintah di bawah ini.

az login

Mengonfigurasi tugas migrasi

Untuk memulai migrasi, buat file JSON dengan detail migrasi. File JSON berisi informasi berikut:

• Edit placeholder << >> di bawah ini dalam baris JSON dan simpan di mesin lokal sebagai <<filename>>.json tempat CLI dipanggil. Dalam tutorial ini, kami telah menyimpan file di c:/migration-CLI/migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

Nota

Saat mengonfigurasi properti JSON untuk migrasi ke server fleksibel Azure Database for PostgreSQL, jika lingkungan sumber Anda adalah Azure Virtual Machine, Anda dapat menentukan jenis sumber menggunakan "sourceType":"AzureVM" properti . Ini membantu layanan migrasi memahami lingkungan tempat data dimigrasikan.

• Jalankan perintah berikut untuk memeriksa apakah ada migrasi yang berjalan. Nama migrasi tersebut bersifat unik di antara semua migrasi pada target server fleksibel Azure Database for PostgreSQL.

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• Dalam langkah-langkah di atas, tidak ada migrasi yang dilakukan sehingga kita mulai dengan migrasi baru dengan menjalankan perintah berikut.

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• Jalankan perintah berikut untuk melihat status migrasi yang dimulai pada langkah sebelumnya. Anda dapat memeriksa status migrasi dengan memberikan nama migrasi.

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• Kemajuan dan status migrasi ditampilkan di Azure CLI.

• Anda juga dapat melihat kemajuan dan status di portal Microsoft Azure.

• Anda dapat membatalkan upaya migrasi yang sedang berlangsung menggunakan cancel perintah . Perintah ini menghentikan upaya migrasi tertentu, dan mengembalikan semua perubahan yang dapat dilakukan di server target Anda. Berikut ini adalah perintah CLI untuk membatalkan migrasi yang memiliki status "Sedang berlangsung".

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

Memantau migrasi

Setelah Anda memilih tombol Mulai validasi dan migrasi , pemberitahuan muncul, dalam beberapa detik, untuk mengatakan bahwa validasi atau pembuatan migrasi berhasil. Anda secara otomatis diarahkan ke halaman Migrasi dari server yang fleksibel. Entri menunjukkan Status sebagai Sedang Berlangsung. Alur kerja membutuhkan waktu 2 hingga 3 menit untuk menyiapkan infrastruktur migrasi dan memeriksa koneksi jaringan.

Kisi yang menampilkan migrasi memiliki kolom berikut: Nama, Status, Mode migrasi, Jenis migrasi, Server sumber, Jenis server sumber, Database, Durasi, dan Waktu mulai. Entri ditampilkan diurutkan menurut Waktu mulai dalam urutan menurun, dengan entri terbaru di bagian atas. Anda dapat menggunakan tombol Refresh di toolbar, untuk menyegarkan status validasi atau migrasi yang dijalankan.

Detail migrasi

Pilih nama migrasi di tabel untuk melihat detail terkait.

Ingatlah bahwa di langkah-langkah sebelumnya, saat membuat migrasi ini, Anda mengonfigurasi opsi migrasi sebagai Validasi dan migrasi. Dalam skenario ini, validasi dilakukan terlebih dahulu, sebelum migrasi dimulai. Setelah substat Lakukan langkah prasyarat selesai, alur kerja berpindah ke substat Validasi yang sedang berlangsung.

• Jika validasi memiliki kesalahan, migrasi akan berpindah ke status Gagal .

• Jika validasi selesai tanpa kesalahan, migrasi dimulai, dan alur kerja berpindah ke substat Migrasi Data.

Detail validasi tersedia di tingkat instans dan database.

• Detail validasi untuk instance
  • Berisi validasi yang terkait dengan pemeriksaan konektivitas, versi sumber, yaitu, versi >PostgreSQL = 9.5, dan pemeriksaan parameter server, apakah ekstensi diaktifkan dalam parameter server server fleksibel Azure Database for PostgreSQL.
• Detail validasi dan migrasi untuk database
  • Ini berisi validasi database individual yang terkait dengan ekstensi dan dukungan kolase di server fleksibel Azure Database for PostgreSQL.

Anda dapat melihat status Validasi dan Status Migrasi di bawah halaman detail migrasi.

Beberapa kemungkinan status migrasi:

Status migrasi

Kedudukan	Description
Sedang berlangsung	Penyiapan infrastruktur migrasi sedang berlangsung, atau migrasi data aktual sedang berlangsung.
Dibatalkan	Migrasi dibatalkan atau dihapus.
Gagal	Migrasi gagal.
Validasi gagal	Validasi gagal.
Berhasil	Migrasi telah berhasil dan selesai.
Menunggu tindakan pengguna	Menunggu tindakan pengguna untuk melakukan cutover.

Detail migrasi

Substatus	Description
Melakukan langkah-langkah prasyarat	Penyiapan infrastruktur sedang berlangsung untuk migrasi data.
Validasi sedang berlangsung	Validasi sedang berlangsung.
Menghapus database di target	Menghapus database yang sudah ada di server target.
Memigrasikan data	Migrasi data sedang berlangsung.
Menyelesaikan migrasi	Migrasi sedang dalam tahap akhir penyelesaian.
Selesai	Migrasi telah selesai.
Gagal	Migrasi gagal.

Substatus validasi

Substatus	Description
Gagal	Validasi gagal.
Berhasil	Validasi berhasil.
Peringatan	Validasi dalam status peringatan.

Memulai alih fungsi

Anda dapat memulai cutover menggunakan portal Microsoft Azure atau Azure CLI.

Portal

Untuk opsi Validasi dan migrasi , menyelesaikan migrasi online mengharuskan pengguna menyelesaikan langkah tambahan, yaitu memicu tindakan cutover. Setelah penyalinan atau kloning data dasar selesai, migrasi berpindah ke Waiting for user action status dan Waiting for cutover trigger substatus. Dalam status ini, pengguna dapat memicu cutover dari portal dengan memilih opsi migrasi.

Sebelum memulai pemotongan, penting untuk memastikan bahwa:

• Penulisan ke sumber dihentikan - latency nilainya adalah 0 atau mendekati 0. Informasi latency dapat diperoleh dari layar detail migrasi seperti yang ditunjukkan di bawah ini:
• latency nilai berkurang menjadi 0 atau mendekati 0
• Nilai latency menunjukkan kapan target terakhir disinkronkan dengan sumbernya. Penulisan ke sumber dapat dihentikan sekarang, dan pemindahan dapat dimulai. Jika terjadi lalu lintas data yang padat di sumber, disarankan untuk menghentikan penulisan data terlebih dahulu agar latency dapat mendekati 0, dan kemudian proses pergantian sistem dimulai.

Operasi cutover menerapkan semua perubahan yang tertunda dari server sumber ke server target, dan menyelesaikan migrasi. Jika Anda memicu cutover, bahkan ketika latency tidak nol, replikasi akan berhenti pada titik waktu tersebut. Semua data dari sumber hingga titik cutover kemudian diterapkan pada target. Jika Anda mengalami latensi 15 menit di titik cutover, semua perubahan yang dilakukan pada data dalam 15 menit terakhir diterapkan ke target.

Waktu tergantung pada backlog perubahan yang terjadi dalam 15 menit terakhir. Oleh karena itu, disarankan agar latensi mencapai nol atau mendekati nol sebelum memicu cutover.

• Migrasi berpindah ke Succeeded status ketika Migrating data substatus atau cutover (dalam migrasi online) berhasil diselesaikan. Jika ada masalah di Migrating data substatus, migrasi akan berpindah ke Failed status.

CLI

Untuk opsi Validasi dan migrasi , menyelesaikan migrasi online mengharuskan pengguna menyelesaikan langkah tambahan, yaitu memicu tindakan cutover. Setelah penyalinan atau kloning data dasar selesai, migrasi berpindah ke Waiting for user action status dan Waiting for cutover trigger substatus. Dalam kondisi ini, pengguna dapat memulai proses alih sistem melalui CLI menggunakan perintah di bawah ini. Transisi juga dapat dipicu dari portal dengan memilih nama migrasi di tabel migrasi.

Sebelum memulai pemotongan, penting untuk memastikan bahwa:

• Penulisan ke sumber dihentikan - latency nilainya adalah 0 atau mendekati 0. Informasi latency dapat diperoleh dari layar detail migrasi seperti yang ditunjukkan di bawah ini:
• latency nilai berkurang menjadi 0 atau mendekati 0
• Nilai latency menunjukkan kapan target terakhir disinkronkan dengan sumbernya. Penulisan ke sumber dapat dihentikan sekarang, dan pemindahan dapat dimulai. Jika terjadi lalu lintas data yang padat di sumber, disarankan untuk menghentikan penulisan data terlebih dahulu agar latency dapat mendekati 0, dan kemudian proses pergantian sistem dimulai.

Operasi cutover menerapkan semua perubahan yang tertunda dari server sumber ke server target, dan menyelesaikan migrasi. Jika Anda memicu cutover, bahkan ketika latency tidak nol, replikasi akan berhenti pada titik waktu tersebut. Semua data dari sumber hingga titik cutover kemudian diterapkan pada target. Jika Anda mengalami latensi 15 menit di titik cutover, semua perubahan yang dilakukan pada data dalam 15 menit terakhir diterapkan ke target.

Waktu tergantung pada backlog perubahan yang terjadi dalam 15 menit terakhir. Oleh karena itu, disarankan agar latensi mencapai nol atau mendekati nol sebelum memicu cutover.

• Migrasi berpindah ke Succeeded status ketika Migrating data substatus atau cutover (dalam migrasi online) berhasil diselesaikan. Jika ada masalah di Migrating data substatus, migrasi akan berpindah ke Failed status.

Untuk memicu peralihan sistem, gunakan perintah berikut:

az postgres flexible-server migration update --subscription <subscription_id> --resource-group <resource_group> --name <server> --migration-name <migration> --cutover

Periksa migrasi saat selesai

Setelah menyelesaikan database, Anda perlu memvalidasi data antara sumber dan target secara manual dan memverifikasi bahwa semua objek dalam database target berhasil dibuat.

Setelah migrasi, Anda dapat melakukan tugas berikut:

• Verifikasi data di server fleksibel Anda dan pastikan data tersebut adalah salinan instans sumber yang tepat.

• Pasca verifikasi, aktifkan opsi ketersediaan tinggi di server fleksibel Anda sesuai kebutuhan.

• Ubah SKU server fleksibel agar sesuai dengan kebutuhan aplikasi. Perubahan ini memerlukan menghidupkan ulang server database.

• Jika Anda mengubah parameter server apa pun dari nilai defaultnya di instans sumber, salin nilai parameter server tersebut di server fleksibel.

• Salin pengaturan server lain, seperti tag, pemberitahuan, dan aturan firewall (jika berlaku), dari instans sumber ke server fleksibel.

• Buat perubahan pada aplikasi Anda untuk mengarahkan string koneksi ke server fleksibel.

• Pantau performa database dengan cermat untuk melihat apakah memerlukan penyetelan performa.

Konten terkait

• Layanan migrasi
• Praktik Terbaik
• Masalah dan batasan yang diketahui
• Penyiapan jaringan
• Validasi pramigrasi