Memigrasikan Azure Database for MySQL - Server Tunggal ke Azure Database for MySQL - Server Fleksibel dengan alat sumber terbuka

Anda dapat memigrasikan instans Azure Database for MySQL - Server Tunggal ke Azure Database for MySQL - Server Fleksibel dengan waktu henti minimum ke aplikasi Anda dengan menggunakan kombinasi alat sumber terbuka seperti mydumper/myloader dan Replikasi data-in.

Catatan

Artikel ini berisi referensi ke istilah slave, istilah yang tidak lagi digunakan Microsoft. Saat istilah dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.

Replikasi Data-in adalah teknik yang mereplikasi perubahan data dari server sumber ke server tujuan berdasarkan metode posisi {i>filedatabase

Jika Anda menyiapkan replikasi Data-in untuk menyinkronkan data dari satu instans Azure Database for MySQL ke yang lain, Anda dapat melakukan {i>cutovedatabasedatabase

Dalam tutorial ini, Anda akan menggunakan replikasi mydumper/myloader dan Data-in untuk memigrasikan database sampel (classicmodels) dari instans Azure Database for MySQL - Server Tunggal ke instans Azure Database for MySQL - Server Fleksibel, lalu menyinkronkan data.

Dalam tutorial ini, Anda akan mempelajari cara:

  • Mengonfigurasikan Pengaturan Jaringan untuk replikasi Data-in untuk skenario yang berbeda.
  • Mengonfigurasikan replikasi Data-in antara primer dan replika.
  • Menguji replikasi.
  • {i>Cutover

Prasyarat

Untuk menyelesaikan tutorial ini, Anda perlu:

  • Instans Server Tunggal Azure Database for MySQL yang menjalankan versi 5.7 atau 8.0.

    Catatan

    Jika Anda menjalankan Server Tunggal Azure Database for MySQL versi 5.6, tingkatkan instans Anda ke 5.7, dan kemudian konfigurasikan data dalam replikasi. Untuk mempelajari selengkapnya, lihat Peningkatan versi utama di Azure Database for MySQL - Server Tunggal.

  • Instans Server Fleksibel Azure Database for MySQL. Selengkapnya, lihat artikel Membuat instans Server Fleksibel di Azure Database for MySQL.

    Catatan

    Mengonfigurasi Replikasi dalam data untuk server ketersediaan tinggi redundan zona tidak didukung. Jika Anda ingin memiliki zona redundan HA untuk server target Anda, lakukan langkah-langkah ini:

    1. Buat server dengan Ketersediaan tinggi di zona redundan diaktifkan
    2. Nonaktifkan ketersediaan tinggi
    3. Ikuti artikel untuk menyiapkan replikasi data masuk
    4. Setelah {i>cutover
    5. Aktifkan ketersediaan tinggi

    Pastikan bahwa GTID_Mode memiliki pengaturan yang sama pada server sumber dan target.

  • Untuk menyambungkan dan membuat {i>databaseGunakan MySQL Workbench untuk menyambungkan dan mengkueri data.

  • Untuk memastikan bahwa Anda memiliki Azure VM yang menjalankan Linux di wilayah yang sama (atau pada VNet yang sama, dengan akses privat) yang meng-{i>hostingdatabase

  • Untuk menginstal klien mysql atau MySQL Workbench (alat klien) di Azure VM Anda. Pastikan Anda dapat tersambung ke server utama dan replika. Untuk tujuan artikel ini, klien mysql diinstal.

  • Untuk menginstal mydumper/myloader di Azure VM Anda. Selengkapnya, lihat artikel mydumper/myloader.

  • Untuk mengunduh dan menjalankan contoh skrip database untuk database classicmodels di server sumber.

  • Konfigurasikan binlog_expire_logs_seconds di server sumber untuk memastikan bahwa binlog tidak dihapus menyeluruh sebelum replika menerapkan perubahan. Setelah berhasil dipotong, Anda dapat mengatur ulang nilai.

Mengonfigurasikan persyaratan jaringan

Untuk mengonfigurasi replikasi Data-in, Anda perlu memastikan bahwa target dapat tersambung ke sumber melalui {i>port

  • Jika titik akhir publik diaktifkan pada sumbernya, maka pastikan target dapat tersambung ke sumber dengan mengaktifkan "Izinkan akses ke layanan Azure" dalam aturan {i>firewall.Aturan Firewall - Azure Database for MySQL.
  • Jika titik akhir privat dan Tolak akses publik diaktifkan pada sumbernya, instal tautan privat di VNet yang sama yang menghosting target. Untuk mempelajari selengkapnya, lihat Private Link - Azure Database for MySQL.

Mengonfigurasikan replikasi Data-in

Untuk mengonfigurasi Replikasi data masuk, lakukan langkah-langkah berikut:

  1. Masuk ke Azure VM tempat Anda menginstal alat klien mysql.

  2. Sambungkan ke sumber dan target menggunakan alat klien mysql.

  3. Gunakan alat klien mysql untuk menentukan apakah log_bin diaktifkan pada sumber dengan menjalankan perintah berikut:

    SHOW VARIABLES LIKE 'log_bin';
    

    Catatan

    Dengan Server Tunggal Azure Database for MySQL dengan penyimpanan besar, yang mendukung hingga 16TB, ini diaktifkan secara {i>default.

    Tip

    Dengan Server Tunggal Azure Database for MySQL, yang mendukung hingga 4TB, ini tidak diaktifkan secara {i>default.replika baca untuk server sumber dan kemudian menghapus replika baca, parameter akan diatur ke ON.

  4. Berdasarkan penegakan SSL untuk server sumber, buat pengguna di server sumber dengan izin replikasi dengan menjalankan perintah yang sesuai.

    Jika Anda menggunakan SSL, jalankan perintah berikut:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
    GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
    

    Jika Anda tidak menggunakan SSL, jalankan perintah berikut:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
    GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
    
  5. Untuk mencadangkan {i>database

    mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl  --regex '^(classicmodels\.)' -L mydumper-logs.txt
    

    Tip

    Opsi -trx-consistency-only diperlukan untuk konsistensi transaksional saat kami mengambil cadangan.

    • Mydumper setara dengan transaksi tunggal mysqldump.
    • Berguna jika semua tabel Anda adalah InnoDB.
    • Utas "utama" hanya perlu menahan kunci global sampai utas "dump" dapat memulai transaksi.
    • Menawarkan durasi penguncian global paling singkat

    Utas "utama" hanya perlu menahan kunci global sampai utas "dump" dapat memulai transaksi.

    Variabel dalam perintah ini dijelaskan di bawah ini:

    HOW-TO-MANAGE-FIREWALL-PORTAL --host: Nama server utama

    • --user: Nama pengguna (dalam format username@servername sejak server utama menjalankan Azure Database for MySQL - Server Tunggal). Anda dapat menggunakan admin server atau pengguna yang memiliki izin SELECT dan RELOAD.
    • --Password: Kata sandi pengguna di atas

    Selengkapnya tentang menggunakan mydumper, lihat mydumper/myloader

  6. Baca {i>filefileoffset

    cat ./backup/metadata
    

    Dalam perintah ini, ./backup mengacu pada direktori output yang digunakan dalam perintah di langkah sebelumnya.

    Hasilnya akan muncul seperti yang ditunjukkan pada gambar berikut:

    Continuous sync with the Azure Database Migration Service

    Pastikan mencatat nama file biner untuk digunakan di langkah-langkah selanjutnya.

  7. Memulihkan {i>database

    myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<Password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txt
    

    Variabel dalam perintah ini dijelaskan di bawah ini:

    • --host: Nama server replika
    • --user: Name pengguna. Anda dapat menggunakan admin server atau pengguna dengan izin baca\tulis yang mampu memulihkan skema dan data ke {i>database
    • --Password: Kata sandi pengguna di atas
  8. Bergantung pada penegakan SSL di server utama, sambungkan ke server replika menggunakan alat klien mysql dan lakukan langkah-langkah berikut.

    • Jika penegakan SSL diaktifkan, maka:

      i. Unduh sertifikat yang diperlukan untuk berkomunikasi melalui SSL dengan Azure Database for MySQL dari sini.

      ii. Buka {i>filenotepad

      SET @cert = '-----BEGIN CERTIFICATE-----
      PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE
      -----END CERTIFICATE-----'
      

      iii. Untuk mengonfigurasi Data dalam replikasi, jalankan perintah berikut:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, @cert);
      

      Catatan

      Tentukan posisi dan nama {i>file

    • Jika penegakan SSL tidak diaktifkan, jalankan perintah berikut:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, ‘’);
      
  9. Untuk memulai replikasi dari server replika, hubungi prosedur yang tersimpan di bawah ini.

    call  mysql.az_replication_start;
    
  10. Untuk memeriksa status replikasi, di server replika, jalankan perintah berikut:

    show slave status \G;
    

    Catatan

    Jika Anda menggunakan MySQL Workbench, pengubah \G tidak diperlukan.

    Jika status Slave_IO_Running dan Slave_SQL_Running adalah Ya dan nilai Seconds_Behind_Master adalah 0, maka replikasi berfungsi dengan baik. Seconds_Behind_Master menunjukkan seberapa lambat replikanya. Jika nilainya selain 0, maka replika sedang memproses pembaruan.

Menguji replikasi (opsional)

Untuk mengonfirmasi bahwa replikasi Data-in berfungsi dengan baik, Anda dapat memverifikasi bahwa perubahan pada tabel pada primer direplikasi ke replika.

  1. Identifikasi tabel yang akan digunakan untuk pengujian, misalnya, tabel Pelanggan, lalu konfirmasikan bahwa jumlah entri yang dikandungnya sama pada server utama dan replika dengan menjalankan perintah berikut pada masing-masing:

    select count(*) from customers;
    
  2. Catat jumlah entri untuk perbandingan selanjutnya.

    Untuk menguji replikasi, coba tambahkan beberapa data ke tabel pelanggan di server utama dan lihat kemudian verifikasi bahwa data baru direplikasi. Dalam hal ini, Anda akan menambahkan dua baris ke tabel di server utama lalu mengonfirmasi bahwa baris tersebut direplikasi di server replika.

  3. Dalam tabel Pelanggan di server utama, sisipkan baris dengan menjalankan perintah berikut:

    insert  into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values
    (<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');
    
  4. Untuk memeriksa status replikasi, hubungi show slave status \G untuk mengonfirmasi bahwa replikasi berfungsi seperti yang diharapkan.

  5. Untuk mengonfirmasi bahwa hitungannya sama, pada server replika, jalankan perintah berikut:

    select count(*) from customers;
    

Memastikan{i> cutover

Untuk memastikan cutover yang berhasil, lakukan tugas-tugas berikut:

  1. Konfigurasikan firewall tingkat server yang sesuai dan aturan jaringan virtual untuk menyambungkan ke server target. Anda dapat membandingkan aturan firewall untuk sumber dan target dari portal.
  2. Konfigurasikan izin tingkat {i>databaseSELECT FROM mysql.user; pada server sumber dan target untuk dibandingkan.
  3. Pastikan semua koneksi masuk ke Server Tunggal Azure Database for MySQL dihentikan.

    Tip

    Anda dapat mengatur Server Tunggal Azure Database for MySQL menjadi membaca saja.

  4. Pastikan bahwa replika telah tercapai dengan server utama dengan menjalankan show slave status \G dan mengonfirmasi nilai untuk parameterSeconds_Behind_Master adalah 0.
  5. Alihkan klien dan aplikasi klien ke instans target Server Fleksibel Azure Database for MySQL.
  6. Lakukan cutover akhir dengan menjalankan prosedur mysql.az_replication_stop yang disimpan, yang akan menghentikan replikasi dari server replika.
  7. Hubungi mysql.az_replication_remove_masteruntuk menghapus konfigurasi replikasi Data-in.

Pada titik ini, aplikasi Anda tersambung ke server Fleksibel Azure Database for MySQL yang baru dan perubahan sumber tidak akan lagi mereplikasi ke target. Membuat dan mengelola aturan firewall Azure Database for MySQL dengan menggunakan portal Microsoft Azure

Langkah berikutnya