Mysql
 sql >> Teknologi Basis Data >  >> RDS >> Mysql

Migrasi Online dari MySQL 5.6 Non-GTID ke MySQL 5.7 dengan GTID

Dalam posting blog ini, kita akan melihat cara melakukan migrasi online dari penyiapan mandiri MySQL 5.6 ke set replikasi baru yang berjalan di MySQL 5.7, disebarkan dan dikelola oleh ClusterControl.

Rencananya adalah menyiapkan tautan replikasi dari cluster baru yang berjalan di MySQL 5.7 ke master yang berjalan di MySQL 5.6 (di luar ketentuan ClusterControl), yang tidak menggunakan GTID. MySQL tidak mendukung pencampuran GTID dan non-GTID dalam satu rantai replikasi. Jadi kita perlu melakukan beberapa trik untuk beralih antara mode non-GTID dan GTID selama migrasi.

Arsitektur dan rencana migrasi kami dapat diilustrasikan seperti di bawah ini:

Pengaturan terdiri dari 4 server, dengan representasi berikut:

  • mysql56a - Master lama - Oracle MySQL 5.6 tanpa GTID
  • Kluster budak:
    • mysql57a - Master baru - Oracle MySQL 5.7 dengan GTID
    • mysql57b - Budak baru - Oracle MySQL 5.7 dengan GTID
  • cc - Server ClusterControl - Server Deployment/management/monitoring untuk node database.

Semua host MySQL 5.7 berjalan di Debian 10 (Buster), sedangkan MySQL 5.6 berjalan di Debian 9 (Stretch).

Menyebarkan Cluster Budak

Pertama, mari kita siapkan cluster slave sebelum kita menyiapkan link replikasi dari master lama. Konfigurasi akhir dari klaster budak akan berjalan di MySQL 5.7, dengan GTID diaktifkan. Instal ClusterControl di server ClusterControl (cc):

$ wget https://severalnines.com/downloads/install-cc
$ chmod 755 install-cc
$ ./install-cc

Ikuti petunjuk sampai penginstalan selesai. Kemudian, atur SSH tanpa kata sandi dari ClusterControl ke mysql57a dan mysql57b:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts
$ ssh-copy-id [email protected] # enter the target host root password
$ ssh-copy-id [email protected] # enter the target host root password

Kemudian, masuk ke ClusterControl UI, isi formulir awal dan buka bagian ClusterControl -> Deploy -> MySQL Replication dan isi berikut ini:

Kemudian klik Lanjutkan dan pilih Oracle sebagai vendor, dan 5.7 sebagai penyedia Versi:kapan. Kemudian lanjutkan ke bagian topologi dan konfigurasikan seperti di bawah ini:

Tunggu hingga penerapan selesai dan Anda akan melihat cluster baru seperti di bawah ini:

Kluster budak kami yang berjalan di MySQL 5.7 dengan GTID sekarang sudah siap.

Mempersiapkan Tuan Tua

Master saat ini yang ingin kami tiru adalah MySQL 5.6 mandiri (log biner diaktifkan, server-id dikonfigurasi, tanpa GTID) dan melayani database produksi. Jadi waktu henti bukanlah pilihan untuk migrasi ini. Di sisi lain, ClusterControl mengonfigurasi MySQL 5.7 baru dengan GTID-enabled yang berarti kita perlu mematikan fungsionalitas GTID di dalam kluster slave agar dapat mereplikasi dengan benar dari master mandiri ini.

Baris berikut menunjukkan konfigurasi terkait replikasi kami saat ini untuk master /etc/mysql/mysql.conf.d/mysqld.cnf di bawah direktif [mysqld]:

server_id=1
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
sync_binlog=1

Verifikasi server MySQL menghasilkan log biner, tanpa GTID:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000007 |   734310 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

Untuk non-GTID, Executed_Gtid_Set diharapkan kosong. Perhatikan bahwa cluster replikasi MySQL 5.7 baru kami yang disebarkan oleh ClusterControl dikonfigurasi dengan GTID diaktifkan.

1) Buat pengguna replikasi untuk digunakan oleh mysql57a:

mysql> CREATE USER 'slave'@'192.168.10.31' IDENTIFIED BY 'slavepassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@192.168.10.31';

2) Nonaktifkan pemulihan otomatis ClusterControl. Di bawah ClusterControl UI -> pilih cluster -> pastikan Auto Recovery Cluster dan Node dimatikan (ikon daya merah), seperti yang ditunjukkan pada tangkapan layar di bawah ini:

Kami tidak ingin ClusterControl memulihkan simpul selama konfigurasi replikasi ini.

3) Sekarang kita perlu membuat cadangan mysqldump lengkap karena ini akan menjadi peningkatan versi utama. Alat pencadangan non-pemblokiran lainnya seperti Percona Xtrabackup atau Pencadangan Perusahaan MySQL tidak mendukung pemulihan ke versi utama yang berbeda. Kita juga perlu mempertahankan file dan posisi log biner saat ini menggunakan flag --master-data:

$ mysqldump -u root -p --single-transaction --master-data=2 --all-databases > mysql56a-fullbackup.sql

Perhatikan bahwa perintah di atas tidak akan memblokir tabel InnoDB karena --single-transaction. Jadi, jika Anda memiliki tabel MyISAM, tabel tersebut akan diblokir selama periode pencadangan untuk menjaga konsistensi.

4) Salin cadangan dari mysql56a ke mysql57a dan mysql57b:

$ scp mysql56a-fullbackup.sql [email protected]:~
$ scp mysql56a-fullbackup.sql [email protected]:~

Menyiapkan Kelompok Budak

Pada fase ini, kita akan mengonfigurasi cluster slave untuk mulai mereplikasi dari master lama, mysql56a tanpa GTID.

1) Hentikan replikasi antara mysql57a dan mysql57b, hapus semua kredensial terkait budak yang dikonfigurasi oleh ClusterControl dan nonaktifkan read-only di mysql57b:

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;

2) Nonaktifkan GTID di mysql57a:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

3) Nonaktifkan GTID di mysql57b:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

4) Kembalikan cadangan mysqldump di mysql57a:

$ mysql -uroot -p < mysql56a-fullbackup.sql

5) Kembalikan cadangan mysqldump di mysql57b:

$ mysql -uroot -p < mysql56a-fullbackup.sql

6) Jalankan skrip pemutakhiran MySQL di mysql57a (untuk memeriksa dan memperbarui semua tabel ke versi saat ini):

$ mysql_upgrade -uroot -p

7) Jalankan skrip pemutakhiran MySQL di mysql57b (untuk memeriksa dan memperbarui semua tabel ke versi saat ini):

$ mysql_upgrade -uroot -p

Kedua server di kluster budak sekarang dipentaskan dengan snapshot data dari master lama, mysql56a, dan sekarang siap untuk direplikasi.

Menyiapkan Replikasi untuk Cluster Slave

1) Reset log biner menggunakan RESET MASTER di mysql57a, jadi kita tidak perlu menentukan file biner dan posisi log nanti di mysql57b. Selain itu, kami menghapus semua referensi GTID yang ada yang dikonfigurasi sebelumnya:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';

2) Pada mysql57a, ambil file binlog dan posisikan dari file dump, mysql56a-fullbackup.sql:

$ head -100 mysql56a-fullbackup.sql | grep LOG_POS
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;

3) Mulai replikasi slave dari master lama, mysql56a ke master baru mysql57a, dengan menentukan nilai MASTER_LOG_FILE dan MASTER_LOG_POS yang benar yang diambil pada langkah sebelumnya. Di mysql57a:

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.22', MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Pastikan Anda melihat baris berikut:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Anda mungkin perlu menunggu hingga mysql57a mengejar mysql56a dengan memantau "Seconds_Behind_Master" dan memastikannya berubah menjadi 0.

4) Pada titik ini, mysql57a sedang mereplikasi data dari mysql56a, yang berarti semua pengguna yang dibuat oleh ClusterControl sekarang hilang dari server (karena mysql57a sekarang mengikuti data di mysql56a). ClusterControl akan memiliki masalah untuk terhubung ke mysql57a dan itu akan muncul sebagai "down". Ini pada dasarnya berarti ClusterControl tidak dapat terhubung ke server MySQL karena hibahnya hilang. Pengguna yang hilang adalah:

Semua kredensial disimpan dengan aman di ClusterControl dan server database itu sendiri. Anda harus memiliki akses root untuk mengambil kembali kredensial dari file yang relevan.

Sekarang, mari buat ulang pengguna yang hilang pada master baru, mysql57a:

a) Buat pengguna cadangan (kata sandi diambil dari /etc/mysql/secrets-backup.cnf di mysql57a):

mysql> CREATE USER [email protected] IDENTIFIED BY '[email protected]!65%JlNB1z';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO [email protected];

b) Buat pengguna replikasi, untuk semua host DB (kata sandi diambil dari variabel repl_password di dalam /etc/cmon.d/cmon_X.cnf pada server ClusterControl, di mana X adalah ID cluster dari cluster slave):

mysql> CREATE USER 'rpl_user'@'192.168.10.31' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.31';
mysql> CREATE USER 'rpl_user'@'192.168.10.32' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.32';

c) Buat dua pengguna database cmon (satu untuk alamat IP dan satu untuk nama host) untuk penggunaan ClusterControl (kata sandi diambil dari variabel mysql_password di dalam /etc/cmon.d/cmon_X.cnf di server ClusterControl, di mana X adalah ID cluster dari budak kelompok):

mysql> CREATE USER [email protected]'192.168.10.19' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.10.19' WITH GRANT OPTION;
mysql> CREATE USER [email protected]'cc.local' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'cc.local' WITH GRANT OPTION;

5) Pada titik ini, mysql57a akan tampak hijau di ClusterControl. Sekarang, kita dapat menyiapkan link replikasi dari mysql57a ke mysql57b. Di mysql57b:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J';
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

**Kita tidak perlu menentukan MASTER_LOG_FILE dan MASTER_LOG_POS karena akan selalu dimulai dengan posisi awal tetap setelah RESET MASTER pada langkah #1.

Pastikan Anda melihat baris berikut:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Pantau status replikasi dan pastikan mysql57b mengikuti mysql57a, dan mysql57a mengikuti mysql56a. Anda mungkin perlu mengaktifkan read-only di mysql57b (dan/atau mysql57a) setelah itu, untuk melindungi dari penulisan yang tidak disengaja. 

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Dari UI ClusterControl, Anda melihat status saat ini di bawah bagian Ikhtisar:

Pada titik ini, master baru mysql57a, 192.168.10.31 mereplikasi dari host mandiri lama mysql56a, 192.168.10.22, sedangkan budak baru mysql57b (hanya-baca) mereplikasi dari mysql57a, 192.168.10.31. Semua node disinkronkan dengan lag replikasi 0.

Atau, Anda dapat mengomentari baris berikut di dalam file konfigurasi MySQL di bawah bagian [mysqld]:

#gtid_mode=ON
#enforce_gtid_consistency=1

Mengaktifkan GTID di Slave Cluster

Perhatikan bahwa untuk MySQL 5.6 dan yang lebih baru, ClusterControl tidak mendukung implementasi non-GTID pada beberapa fitur manajemennya lagi seperti Rebuild Replication Slave dan Change Replication Master. Jadi, selama cut-off time (saat Anda mengarahkan aplikasi ke cluster baru) dari server MySQL mandiri (mysql56a), disarankan untuk mengaktifkan kembali GTID di mysql57a dan mysql57b dengan langkah-langkah berikut:

1) Pastikan untuk mematikan fitur pemulihan otomatis ClusterControl:

2) Selama jendela pemeliharaan cut-off, kita harus berhenti mereplikasi dari master lama, mysql56a, hapus semua konfigurasi slave di mysql57a dan aktifkan kembali GTID. Di mysql57a, jalankan perintah berikut dalam urutan yang benar:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

Pada titik ini, secara praktis aman bagi aplikasi Anda untuk mulai menulis ke master baru, mysql57a. MySQL lama yang berdiri sendiri sekarang keluar dari rantai replikasi dan dapat dimatikan.

3) Ulangi langkah yang sama untuk mysql57b. Ingatlah untuk mengikuti langkah-langkah dalam urutan yang benar:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

4) Kemudian, reset master pada master baru, mysql57a:

mysql> RESET MASTER;

3) Kemudian pada slave baru, mysql57b setup link replikasi menggunakan GTID ke mysql57a:

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Pastikan Anda melihat bidang Retrieved_Gtid_Set dan Executed_Gtid_Set memiliki nilai GTID-nya.

4) Pada titik ini, kami telah memulihkan kembali konfigurasi replikasi seperti yang telah dikonfigurasi sebelumnya oleh ClusterControl selama tahap penyebaran cluster. Kami kemudian dapat mengaktifkan read-only pada slave baru, mysql57b untuk melindunginya dari penulisan yang tidak disengaja:

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Terakhir, aktifkan kembali pemulihan otomatis ClusterControl untuk cluster, dengan mengubah ikon daya menjadi hijau. Anda kemudian dapat menonaktifkan master lama, mysql56a. Kami baru saja menyelesaikan migrasi online kami dari MySQL 5.6 ke MySQL 5.7 dengan waktu henti yang sangat minimal. Langkah serupa juga dapat diterapkan untuk migrasi ke MySQL 8.0.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Bagaimana cara mencadangkan dan memulihkan basis data MySQL?

  2. Periksa dan Optimalkan Database MySQL Secara Otomatis dengan Crontab/Cron

  3. Kapan saya harus menggunakan indeks komposit?

  4. PHP Peringatan:mysqli_connect():(HY000/2002):Koneksi ditolak

  5. JDBC Buat Tabel Contoh Penggunaan Pernyataan