Bagikan melalui


Tutorial: Melakukan migrasi online dari Amazon Aurora PostgreSQL ke Azure Database for PostgreSQL dengan Pratinjau layanan migrasi

Artikel ini membahas cara memigrasikan database PostgreSQL Anda dari Amazon Aurora 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.

  • Prasyarat
  • Lakukan migrasi
  • Memantau migrasi
  • Peralihan
  • Periksa migrasi saat selesai

Prasyarat

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.

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.

Menginstal test_decoding - penyiapan sumber

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

Mengonfigurasi penyiapan target

  • Sebelum bermigrasi, Azure Database for PostgreSQL – Server fleksibel harus dibuat.
  • SKU yang disediakan untuk Azure Database for PostgreSQL – Server fleksibel harus cocok dengan sumbernya.
  • Untuk membuat Azure Database for PostgreSQL baru, kunjungi Membuat Azure Database for PostgreSQL

Mengaktifkan CDC sebagai sumber

  • test_decoding plugin decoding logis menangkap rekaman yang diubah dari sumbernya.
  • Untuk mengizinkan pengguna migrasi mengakses hak istimewa replikasi, jalankan perintah berikut:
GRANT rds_replication TO <<username>>;
  • Di sumbernya, instans PostgreSQL, ubah parameter berikut (grup parameter Kluster DB) dengan membuat grup parameter baru:

    • Mengeset rds.logical_replication = 1
    • Atur max_replication_slots ke nilai yang lebih besar dari satu; nilai harus lebih besar dari jumlah database yang dipilih untuk migrasi.
    • Atur max_wal_senders ke nilai yang lebih besar dari satu. Setidaknya harus sama max_replication_slotsdengan , ditambah jumlah pengirim yang sudah digunakan pada instans Anda.
    • Parameter wal_sender_timeout mengakhiri koneksi replikasi tidak aktif lebih lama dari jumlah milidetik yang ditentukan. Default untuk instans Amazon Aurora PostgreSQL adalah 30000 milliseconds (30 seconds). 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 penyimpanan untuk menyimpan log, pastikan Anda memiliki ruang tabel yang memadai menggunakan disk terkelola yang 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 bahwa 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 layanan migrasi di Azure Database for PostgreSQL, Anda mungkin perlu memverifikasi ekstensi ke instans PostgreSQL sumber Anda. Ekstensi menyediakan fungsionalitas dan fitur tambahan yang mungkin diperlukan untuk aplikasi Anda. Pastikan untuk memverifikasi ekstensi pada instans PostgreSQL sumber sebelum memulai proses migrasi.

Aktifkan ekstensi yang didukung yang diidentifikasi dalam instans PostgreSQL sumber pada server fleksibel Azure Database for PostgreSQL target.

Untuk informasi selengkapnya tentang ekstensi, kunjungi Ekstensi di Azure Database for PostgreSQL.

Catatan

Hidupkan ulang diperlukan ketika ada perubahan pada shared_preload_libraries parameter .

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 pg_dumpall utilitas dengan --globals-only bendera untuk mengekspor objek global seperti peran 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, pengguna dengan hak istimewa superuser harus memiliki hak istimewa tersebut 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.

Nonaktifkan ketersediaan tinggi (keandalan) dan replika baca dalam 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 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.

Lakukan migrasi

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 Azure Database for PostgreSQL - Server Fleksibel 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.

Mengonfigurasi tugas migrasi

Layanan migrasi dilengkapi dengan pengalaman sederhana berbasis wizard pada portal Azure. Berikut cara untuk memulainya:

  1. Buka browser web Anda, dan buka portal. Masukkan info masuk Anda untuk masuk ke portal. Tampilan default adalah dasbor layanan Anda.

  2. Buka target Server Fleksibel Azure Database for PostgreSQL Anda.

  3. Di tab Gambaran Umum Server Fleksibel, di menu sebelah kiri, gulir ke bawah ke Migrasi dan pilih.

    Cuplikan layar pilihan Migrasi.

  4. Pilih tombol Buat untuk bermigrasi dari Amazon Aurora ke Azure Database for PostgreSQL - Server Fleksibel. Jika ini pertama kalinya Anda menggunakan layanan migrasi, kisi kosong muncul dengan perintah untuk memulai migrasi pertama Anda.

    Cuplikan layar pembuatan migrasi.

    Jika Anda telah membuat migrasi ke target Azure Database for PostgreSQL, kisi berisi informasi tentang upaya migrasi.

  5. Pilih tombol **Buat **. Kemudian, Anda akan melalui serangkaian tab berbasis wizard untuk membuat migrasi ke target Azure Database for PostgreSQL ini dari instans sumber PostgreSQL.

Siapkan

Tab pertama adalah tab Penyiapan , di mana pengguna perlu memberikan detail migrasi seperti jenis sumber nama migrasi untuk memulai migrasi.

Cuplikan layar migrasi Penyiapan di portal Azure.

  • 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:

    • Validasi - Memeriksa kesiapan server dan database Anda untuk migrasi ke target.
    • Migrasi - Melewati validasi dan memulai migrasi.
    • Validasi dan Migrasi—Melakukan validasi sebelum memicu migrasi. Migrasi dipicu hanya jika tidak ada kegagalan validasi.

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.

  • Mode migrasi memungkinkan Anda memilih mode untuk migrasi. Offline adalah opsi default.

Pilih tombol Berikutnya: Sambungkan ke Sumber .

Pilih Server Runtime

Runtime Server migrasi adalah fitur khusus dalam layanan migrasi, yang dirancang untuk bertindak sebagai server perantara selama migrasi. Ini adalah instans Azure Database for PostgreSQL - Server Fleksibel 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.

Cuplikan layar halaman Server Runtime Migrasi.

Sambungkan ke sumber

Tab Sambungkan ke Sumber meminta Anda untuk memberikan detail yang terkait dengan Sumber yang dipilih di Tab Penyetelan, yang merupakan Sumber database.

Cuplikan layar Connectsourcemigration.

  • Nama Server - Berikan Nama Host atau alamat IP instans PostgreSQL sumber
  • Port - Nomor port server Sumber
  • Nama masuk admin server - Nama pengguna server PostgreSQL sumber
  • Kata Sandi - Kata sandi server PostgreSQL Sumber
  • Mode SSL—Nilai yang didukung lebih disukai dan diperlukan. Ketika SSL di server Source PostgreSQL NONAKTIF, gunakan SSLMODE=prefer. Jika SSL di server sumber aktif, gunakan SSLMODE=require. Nilai SSL dapat ditentukan dalam file Postgresql.conf.
  • Uji Koneksi—Melakukan pengujian konektivitas antara target dan Sumber. Setelah koneksi berhasil, pengguna dapat melanjutkan dengan langkah berikutnya. Jika tidak, kita perlu mengidentifikasi masalah jaringan antara target dan Sumber dan memverifikasi nama pengguna/kata sandi untuk Sumber. Membuat koneksi pengujian membutuhkan waktu beberapa menit.

Setelah koneksi pengujian berhasil, pilih target Berikutnya: Pilih Migrasi

Pilih target migrasi

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

Cuplikan layar migrasi target sambungkan.

  • Nama pengguna admin - Nama pengguna admin server PostgreSQL target
  • Kata Sandi - Kata sandi server PostgreSQL target
  • Uji Koneksi - Melakukan pengujian konektivitas antara target dan Sumber. Setelah koneksi berhasil, pengguna dapat melanjutkan dengan langkah berikutnya. Jika tidak, kita perlu mengidentifikasi masalah jaringan antara target dan Sumber dan memverifikasi nama pengguna/kata sandi untuk target. Uji koneksi membutuhkan waktu beberapa menit untuk membuat koneksi antara target dan sumber.

Setelah koneksi pengujian berhasil, pilih Berikutnya: Pilih Database untuk Migrasi

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.

Cuplikan layar FetchDBmigration.

Setelah memilih database, pilih Berikutnya: Ringkasan

Ringkasan

Tab Ringkasan meringkas semua detail Sumber dan target untuk membuat validasi atau migrasi. Tinjau detail dan pilih tombol mulai.

Cuplikan layar migrasi Ringkasan.

Memantau migrasi

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.

Cuplikan layar Pantau migrasi.

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 kisi untuk melihat detail terkait.

Saat validasi atau migrasi dibuat, validasi atau migrasi berpindah ke status InProgress dan substrat PerformingPreRequisiteSteps . Alur kerja membutuhkan waktu 2-3 menit untuk menyiapkan infrastruktur migrasi dan koneksi jaringan.

Detail migrasi

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.

  • 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.

Anda dapat melihat hasil validasi dan migrasi di tingkat instans dan database.

Cuplikan layar migrasi Detail.

Beberapa kemungkinan status migrasi:

Status migrasi

Provinsi Deskripsi
InProgress Penyiapan infrastruktur migrasi sedang berlangsung, atau migrasi data aktual sedang berlangsung.
Canceled 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.

Sub-status migrasi

Substate Deskripsi
PerformingPreRequisiteSteps Penyiapan infrastruktur sedang berlangsung untuk migrasi data.
Validasi sedang Berlangsung Validasi dalam proses.
MigratingData Migrasi data sedang berlangsung.
CompletingMigration Migrasi sedang dalam tahap akhir penyelesaian.
Selesai Migrasi telah selesai.
Gagal Migrasi gagal.

Substatus validasi

Substate Deskripsi
Gagal Validasi gagal.
Berhasil Validasi berhasil.
Peringatan Validasi sedang dalam peringatan.

Peralihan

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 WaitingForUserAction status dan substat 'WaitingForCutoverTrigger'. Dalam status ini, pengguna dapat memicu cutover dari portal dengan memilih migrasi.

Sebelum memulai cutover, 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:

    Cuplikan layar migrasi Langsung.

  • 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 cutover dapat dimulai. Jika ada lalu lintas padat di Sumber, disarankan untuk menghentikan penulisan terlebih dahulu sehingga Latency dapat mendekati 0, dan kemudian cutover dimulai. Operasi Cutover menerapkan semua perubahan yang tertunda dari Sumber ke Target dan menyelesaikan migrasi. Jika Anda memicu "Cutover" bahkan dengan nonzero Latency, replikasi berhenti sampai 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 memicu cutover.

    Cuplikan layar Confirmcutovermigration.

  • 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.

    Cuplikan layar migrasi Keberhasilan.

Periksa migrasi saat selesai

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:

  • 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.