Acara
10 Jun, 23 - 12 Jun, 23
Bergabunglah dengan kami untuk acara gratis & virtual ini, terjadi 10-12 Jun.
DaftarBrowser ini sudah tidak didukung.
Mutakhirkan ke Microsoft Edge untuk memanfaatkan fitur, pembaruan keamanan, dan dukungan teknis terkini.
Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini membahas cara memigrasikan database PostgreSQL Anda dari Google Cloud SQL for PostgreSQL ke Azure Database for PostgreSQL secara online.
Layanan migrasi di Azure Database for PostgreSQL adalah layanan terkelola penuh yang terintegrasi ke dalam portal Azure dan Azure CLI. Ini dirancang untuk menyederhanakan perjalanan migrasi Anda ke server Azure Database for PostgreSQL.
Untuk menyelesaikan 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.
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.
Catatan
Layanan migrasi di Azure Database for PostgreSQL mendukung koneksi menggunakan alamat IP untuk Sumber Google Cloud SQL for PostgreSQL. Format myproject:myregion:myinstance
tidak didukung.
test_decoding
plugin dekoding logika menangkap rekaman yang diubah dari sumber.Alter user <<username>> with REPLICATION;
Buka instans Google Cloud SQL PostgreSQL di Google Cloud Console, pilih nama instans untuk membuka halaman detailnya, pilih tombol Edit, dan di bagian Bendera, ubah bendera berikut:
cloudsql.logical_decoding = on
max_replication_slots
ke nilai yang lebih besar dari satu; nilainya harus lebih besar dari jumlah database yang dipilih untuk migrasi.max_wal_senders
ke nilai yang lebih besar dari satu. Setidaknya harus sama dengan max_replication_slots
, ditambah jumlah pengirim yang sudah digunakan pada instans Anda.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.Pada Server Fleksibel tujuan, untuk mencegah migrasi Online kehabisan ruang penyimpanan untuk menyimpan log, pastikan Anda memiliki ruang tablespace yang cukup menggunakan disk terkelola yang sudah dipersiapkan. Untuk mencapai hal ini, nonaktifkan parameter azure.enable_temp_tablespaces_on_local_ssd
server selama durasi migrasi, dan pulihkan ke status asli setelah migrasi.
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.
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 di Azure Database for PostgreSQL.
Catatan
Mulai ulang diperlukan saat Anda membuat perubahan apa pun pada shared_preload_libraries
parameter .
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.
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 pada pengguna harus dihapus sebelum migrasi. Pastikan Anda menyesuaikan izin dan peran yang 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.
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 yang lancar tanpa variabel tambahan yang diperkenalkan oleh HA dan Replika Baca. Setelah migrasi selesai dan database stabil, Anda dapat melanjutkan untuk mengaktifkan fitur-fitur ini untuk meningkatkan ketersediaan dan skalabilitas lingkungan database Anda di Azure.
Anda dapat bermigrasi dengan menggunakan portal Azure atau Azure CLI.
portal Azure memberikan pengalaman berbasis wizard sederhana dan intuitif yang memandu Anda melalui migrasi. Mengikuti langkah-langkah yang diuraikan dalam tutorial ini, Anda dapat mentransfer database Anda dengan mulus ke server fleksibel Azure Database for PostgreSQL dan memanfaatkan fitur dan skalabilitasnya yang canggih.
Untuk bermigrasi dengan portal Azure, Anda terlebih dahulu mengonfigurasi tugas migrasi, menyambungkan ke sumber dan target, lalu melakukan migrasi.
Layanan migrasi dilengkapi dengan pengalaman sederhana berbasis wizard pada portal Azure. Berikut cara untuk memulainya:
Buka browser web Anda, dan buka portal. Masukkan kredensial Anda untuk masuk. Tampilan default adalah dasbor layanan Anda.
Pergi ke Server Fleksibel Azure Database untuk PostgreSQL Anda.
Di tab Gambaran Umum Server Fleksibel, di menu sebelah kiri, gulir ke bawah ke Migrasi dan pilih.
Pilih tombol Buat untuk bermigrasi dari Google Cloud SQL for PostgreSQL ke server fleksibel Azure Database for PostgreSQL. Jika ini pertama kalinya Anda menggunakan layanan migrasi, kisi kosong muncul dengan perintah untuk memulai migrasi pertama Anda.
Jika Anda sudah membuat migrasi ke target Azure Database for PostgreSQL, tabel akan menampilkan informasi tentang migrasi yang telah diupayakan.
Pilih tombol Buat. Kemudian, Anda akan mengikuti panduan bertahap melalui serangkaian tab untuk melakukan migrasi ke target Azure Database for PostgreSQL ini dari instans sumber PostgreSQL.
Tab pertama adalah tab Penyiapan , di mana pengguna perlu memberikan detail migrasi seperti jenis sumber nama migrasi untuk memulai migrasi.
Nama migrasi adalah pengidentifikasi unik untuk setiap migrasi ke 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 Server Fleksibel yang sama yang dapat memiliki nama yang sama.
Jenis Server Sumber — Bergantung pada sumber PostgreSQL, Anda dapat memilih jenis sumber yang sesuai, seperti layanan PostgreSQL berbasis cloud, penyiapan lokal, atau komputer virtual.
Opsi Migrasi memungkinkan Anda melakukan validasi sebelum memicu migrasi. Anda dapat memilih salah satu opsi berikut:
Memilih opsi Validasi atau Validasi dan Migrasi selalu merupakan praktik yang baik saat melakukan validasi pramigrasi sebelum menjalankan migrasi. Untuk mempelajari selengkapnya tentang validasi pramigrasi, lihat dokumentasi ini.
Pilih tombol Berikutnya: Sambungkan ke Sumber .
Server Runtime migrasi adalah fitur khusus dalam layanan migrasi, yang dirancang untuk bertindak sebagai server penghubung 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 Runtime Server, kunjungi Runtime Server Migrasi.
Tab Sambungkan ke Sumber meminta Anda untuk memberikan detail yang terkait dengan Sumber yang dipilih di Tab Penyetelan, yang merupakan Sumber database.
Setelah koneksi pengujian berhasil, pilih target Berikutnya: Pilih Migrasi
Tab pilih target migrasi menampilkan metadata untuk target Server Fleksibel, seperti nama langganan, grup sumber daya, nama server, lokasi, dan versi PostgreSQL.
flexibleserver.example.com
, 198.1.0.2
, atau FQDN PostgreSQL seperti flexibleserver.postgres.database.azure.com
, jika server DNS kustom berisi DNS zone 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.Setelah koneksi pengujian berhasil, pilih Berikutnya: Pilih Database untuk Migrasi
Di bawah tab ini, daftar database pengguna berada di dalam server sumber yang dipilih di tab penyiapan. Anda dapat memilih dan memigrasikan hingga delapan database dalam satu upaya migrasi. Jika ada lebih dari delapan database pengguna, proses migrasi diulang antara server sumber dan target untuk kumpulan database berikutnya.
Setelah memilih database, pilih Berikutnya: Ringkasan
Tab Ringkasan meringkas semua detail Sumber dan target untuk membuat validasi atau migrasi. Tinjau detail dan pilih tombol mulai.
Setelah Anda memilih tombol mulai, pemberitahuan akan muncul dalam beberapa detik yang mengatakan bahwa validasi atau pembuatan migrasi berhasil. Anda kemudian akan secara otomatis diarahkan ke halaman Migrasi Server Fleksibel, yang memiliki entri baru untuk validasi atau migrasi yang baru dibuat.
Kisi yang menampilkan migrasi memiliki kolom ini: Nama, Status, Mode migrasi, Jenis migrasi, Server sumber, Jenis server sumber, Database, Durasi, dan Waktu mulai. Entri ditampilkan dalam urutan menurun dari waktu mulai, dengan entri terbaru di bagian atas. Anda dapat menggunakan tombol refresh untuk me-refresh status validasi atau migrasi. Pilih nama migrasi di tabel untuk melihat detail terkait.
Saat validasi atau migrasi dibuat, maka akan berpindah ke status InProgress dan substrat PerformingPreRequisiteSteps. Alur kerja membutuhkan waktu 2-3 menit untuk menyiapkan infrastruktur migrasi dan koneksi jaringan.
Di tab Penyiapan, kami telah memilih opsi migrasi sebagai Migrasi dan Validasi. Dalam skenario ini, validasi dilakukan terlebih dahulu sebelum migrasi dimulai. Setelah substat PerformingPreRequisiteSteps selesai, alur kerja berpindah ke substat Validasi sedang Berlangsung.
Anda dapat melihat hasil validasi dan migrasi di tingkat instans dan database.
Beberapa kemungkinan status migrasi:
Negara | Deskripsi |
---|---|
InProgress | Penyiapan infrastruktur migrasi sedang berlangsung, atau migrasi data aktual sedang berlangsung. |
Dibatalkan | Migrasi dibatalkan atau dihapus. |
Gagal | Migrasi telah gagal. |
Validasi Gagal | Validasi gagal. |
Berhasil | Migrasi telah berhasil dan selesai. |
WaitingForUserAction | Hanya berlaku untuk migrasi online. Menunggu tindakan pengguna untuk melakukan cutover. |
Bagian Negara | Deskripsi |
---|---|
MelakukanLangkahLangkahPrasyarat | Penyiapan infrastruktur sedang berlangsung untuk migrasi data. |
Validasi sedang Berlangsung | Validasi dalam proses. |
MigratingData | Migrasi data sedang berlangsung. |
MenyelesaikanMigrasi | Migrasi sedang dalam tahap akhir penyelesaian. |
Selesai | Migrasi telah selesai. |
Gagal | Migrasi gagal. |
Bagian Negara | Deskripsi |
---|---|
Gagal | Validasi gagal. |
Berhasil | Validasi berhasil. |
Peringatan | Validasi berstatus peringatan. |
Jika ada Migrasi dan Validasi dan Migrasi, menyelesaikan migrasi Online memerlukan langkah lain—pengguna harus mengambil tindakan Cutover. Setelah salinan/klon data dasar selesai, migrasi berpindah ke keadaan WaitingForUserAction
dan subkeadaan WaitingForCutoverTrigger
. Dalam kondisi ini, pengguna dapat memicu cutover dari portal dengan memilih opsi migrasi.
Sebelum memulai peralihan sistem, 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 Sumber. Pada titik ini, penulisan ke Sumber dapat dihentikan, dan alih fungsi dapat dimulai. Jika ada lalu lintas padat di Sumber, disarankan untuk menghentikan aktivitas penulisan terlebih dahulu sehingga Latency
dapat mendekati 0, dan setelah itu, cutover dapat dimulai.
Operasi Cutover menerapkan semua perubahan yang tertunda dari Sumber ke Target dan menyelesaikan migrasi. Jika Anda memicu "Cutover" bahkan dengan nilai bukan nol Latency,
, replikasi akan berhenti sampai pada titik waktu tersebut. Semua data ada di Sumber hingga titik cutover diterapkan ke target. Katakanlah latensi adalah 15 menit di titik cutover, sehingga semua data yang diubah 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 memulai proses cutover (alih sistem).
Migrasi berpindah ke Succeeded
status saat Migrating Data
substat atau cutover (dalam migrasi Online) berhasil diselesaikan. Jika ada masalah di sub-status Migrating Data
, migrasi berpindah ke status Failed
.
Setelah menyelesaikan database, Anda perlu memvalidasi data antara sumber secara manual, dan target dan memverifikasi bahwa semua objek dalam database target berhasil dibuat.
Setelah migrasi, Anda dapat melakukan tugas berikut:
Acara
10 Jun, 23 - 12 Jun, 23
Bergabunglah dengan kami untuk acara gratis & virtual ini, terjadi 10-12 Jun.
Daftar