Thursday, November 21, 2024

Đồng bộ MySQL/MariaDB không downtime sử dụng replication

-

1. Tổng quan.

Để sync dữ liệu từ cụm Master-Slave hiện tại sang một cụm khác đang chạy Cluster, bạn có thể thực hiện bằng cách sử dụng một số phương án khả thi. Việc này sẽ phụ thuộc vào loại cluster bạn đang sử dụng (MySQL Cluster, Galera Cluster, hoặc một giải pháp khác) và yêu cầu về downtime, khả năng nhất quán và đồng bộ giữa các hệ thống.

2. Giới thiệu một số phương pháp đồng bộ database.

Sử dụng Replication từ Master đến Cluster.

  • Phương án: Dùng chức năng Replication của MySQL/MariaDB để tạo một luồng Replication từ Master trong cụm hiện tại (Master-Slave) đến cụm Cluster mới. Điều này cho phép dữ liệu từ Master hiện tại được đồng bộ với cụm Cluster.
  • Cách thực hiện:
    • Thiết lập replication từ Master trong cụm Master-Slave đến một node trong cụm Cluster.
    • Cấu hình node trong cụm Cluster để tiếp nhận replication từ Master. Node này sẽ đóng vai trò như một Slave đối với Master hiện tại.
    • Các node trong cụm Cluster sẽ đồng bộ dữ liệu nội bộ với nhau (nếu bạn sử dụng Galera Cluster hoặc MySQL InnoDB Cluster).
    • Kiểm tra quá trình replication để đảm bảo rằng dữ liệu được chuyển đổi một cách đầy đủ.
  • Ưu điểm: Dữ liệu từ cụm hiện tại có thể được đồng bộ hóa trực tiếp mà không cần ngắt kết nối Master-Slave hiện tại.
  • Nhược điểm: Tăng tải trên Master hiện tại, cần cấu hình chính xác trên cụm Cluster để tránh mất đồng bộ.

Sử dụng Logical Backup với mysqldump.

  • Phương án: Dùng công cụ mysqldump để tạo bản sao logic của toàn bộ cơ sở dữ liệu từ Master hoặc Slave hiện tại, sau đó import dữ liệu vào cụm Cluster mới.
  • Cách thực hiện:
    • Chạy lệnh mysqldump trên Master hoặc Slave hiện tại để tạo bản sao của tất cả các cơ sở dữ liệu hoặc các cơ sở dữ liệu cụ thể.
    • Chuyển bản sao đó đến một node trong cụm Cluster.
    • Import dữ liệu vào cụm Cluster thông qua một node bất kỳ. Các node còn lại trong Cluster sẽ tự động đồng bộ dữ liệu (trong trường hợp sử dụng Galera Cluster hoặc MySQL InnoDB Cluster).
    • Thiết lập replication liên tục nếu cần để giữ dữ liệu đồng bộ giữa các cụm.
  • Ưu điểm: Giải pháp đơn giản, không yêu cầu cấu hình phức tạp.
  • Nhược điểm: Có thể tốn thời gian đối với cơ sở dữ liệu lớn, và sẽ có downtime trong quá trình dump và import.

Sử dụng Physical Backup với Percona XtraBackup hoặc Mariabackup.

  • Phương án: Dùng công cụ sao lưu vật lý như Percona XtraBackup hoặc Mariabackup để tạo bản sao toàn bộ cơ sở dữ liệu từ cụm Master-Slave và sau đó khôi phục nó trên cụm Cluster.
  • Cách thực hiện:
    • Sao lưu dữ liệu từ Slave trong cụm hiện tại bằng công cụ XtraBackup hoặc Mariabackup.
    • Chuyển bản sao lưu đến cụm Cluster.
    • Khôi phục dữ liệu trên cụm Cluster từ bản sao lưu đã tạo.
    • Thiết lập replication từ Master hiện tại đến cụm Cluster nếu cần để đảm bảo dữ liệu đồng bộ liên tục.
  • Ưu điểm: Sao lưu vật lý thường nhanh hơn nhiều so với sao lưu logic (mysqldump), giảm downtime.
  • Nhược điểm: Cần kiến thức về backup và restore vật lý.

Thiết lập Replication đa nguồn (Multi-Source Replication).

  • Phương án: Nếu bạn đang sử dụng MariaDB hoặc MySQL phiên bản hỗ trợ multi-source replication, bạn có thể thiết lập replication từ cả Master trong cụm hiện tại và cụm Cluster đến một node trung gian để hợp nhất dữ liệu.
  • Cách thực hiện:
    • Thiết lập node trung gian để nhận dữ liệu từ Master trong cụm hiện tại.
    • Thiết lập node trung gian để gửi dữ liệu đã hợp nhất đến cụm Cluster mới.
  • Ưu điểm: Giữ nguyên trạng thái của cả hai cụm, không ảnh hưởng đến môi trường hiện tại.
  • Nhược điểm: Quá trình cấu hình phức tạp, yêu cầu phải cẩn thận để tránh xung đột dữ liệu.

Sử dụng công cụ đồng bộ hóa dữ liệu pt-table-sync hoặc gh-ost.

  • Phương án: Sử dụng các công cụ chuyên biệt để đồng bộ dữ liệu giữa hai cụm (có thể thực hiện với pt-table-sync từ bộ công cụ Percona hoặc gh-ost của GitHub).
  • Cách thực hiện:
    • Sử dụng pt-table-sync để đảm bảo dữ liệu giữa Master trong cụm hiện tại và cụm Cluster mới là nhất quán.
    • gh-ost có thể giúp di chuyển hoặc đồng bộ các bảng mà không làm gián đoạn dịch vụ.
  • Ưu điểm: Công cụ chuyên nghiệp giúp đảm bảo đồng bộ dữ liệu mà không gây downtime lớn.
  • Nhược điểm: Cần kiến thức về các công cụ này và cấu hình phức tạp.

Như vậy, nếu bạn cần đồng bộ liên tục sử dụng replication từ Master đến cụm Cluster hoặc thiết lập replication đa nguồn. Nếu bạn có thể chấp nhận downtime tạm thời dùng mysqldump hoặc sao lưu vật lý với XtraBackup để tạo và khôi phục cơ sở dữ liệu. Nếu muốn tránh downtime sử dụng công cụ đồng bộ hóa dữ liệu hoặc replication mà không ngừng dịch vụ.

3. Quy trình triển khai đồng bộ database sử dụng replication từ Master/Slave đến cụm Cluster mới.

Để đồng bộ cơ sở dữ liệu từ cụm Master-Slave sang cụm Cluster mà không gây downtime, bạn có thể thực hiện replication liên cụm. Đây là một giải pháp không downtime và phổ biến trong trường hợp chuyển đổi hoặc đồng bộ cơ sở dữ liệu giữa các hệ thống. Quy trình cơ bản bao gồm thiết lập một Slave trên cụm Cluster để nhận dữ liệu từ cụm Master-Slave. Sau khi đồng bộ hoàn tất, bạn có thể chuyển đổi sang sử dụng cụm Cluster mà không cần downtime.

Trên MasterDB 10.237.7.71.

Trên MasterDB sử dụng lệnh SHOW MASTER STATUS để lấy tên file log sử dụng để đồng bộ, ở đây mình có file mariadb-bin.000001.

shell> mysql -e "SHOW MASTER STATUS;"
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000001 |  1331968 |              |                  |
+--------------------+----------+--------------+------------------+

Để bổ sung thêm IP 10.237.7.74 cho user replicator, bạn sử dụng lệnh SQL để tạo một người dùng mới với cùng tên nhưng với IP khác sau đó dùng lệnh mysql -e "GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'10.237.7.74';" để cấp quyền replication cho user replicator từ địa chỉ IP 10.237.7.74. Điều này cho phép user replicator có thể thực hiện các tác vụ replication từ máy chủ master đến máy chủ slave.

mysql -e "CREATE USER 'replicator'@'10.237.7.74' IDENTIFIED BY 'password';"
mysql -e "GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'10.237.7.74';"
mysql -e "FLUSH PRIVILEGES;"

Thiết lập một node bất kỳ trên cụm Cluster làm Slave, ví dụ 10.237.7.74.

Trên cụm Cluster (MariaDB Galera Cluster hoặc MySQL Cluster), chọn một node trong Cluster và thiết lập node đó làm Slave của cụm Master-Slave hiện tại, ví dụ mình chọn node có địa chỉ IP là 10.237.7.74.

Thay đổi file config /etc/mysql/mariadb.conf.d/50-server.cnf trên node này như dưới. Vì bạn đang cấu hình cho Slave node, bạn cần thiết lập server_id và chỉ định replication với replicate-do-db:

[mysqld]
server_id=3
replicate-do-db=keystone_sw_auth_2
  • server_id=3: ID của Slave node, cần khác với Master và các Slave khác.
  • replicate-do-db=keystone_sw_auth_2: Slave sẽ chỉ sao chép các thay đổi của database keystone_sw_auth_2.

Bạn cũng có thể chỉnh sửa các tham số hiệu năng như sau:

[mysqld]
max_connections         = 1000
innodb_buffer_pool_size = 256M
innodb_flush_log_at_trx_commit = 1
sync_binlog             = 1
  • innodb_buffer_pool_size: Tùy chỉnh kích thước của bộ nhớ đệm InnoDB để tối ưu hóa hiệu suất.
  • sync_binlog=1: Đảm bảo rằng binlog được ghi đồng bộ với mỗi giao dịch.

Dưới đây là full cấu hình của mình, bạn hãy tham khảo nó.

cat > /etc/mysql/mariadb.conf.d/50-server.cnf << 'OEF'
[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
log-bin
server_id=3
replicate-do-db=keystone_sw_auth_2
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc_messages_dir = /usr/share/mysql
lc_messages     = en_US
skip-external-locking
bind-address            = 0.0.0.0
max_connections         = 1000
connect_timeout         = 5
wait_timeout            = 3600
max_allowed_packet      = 16M
thread_cache_size       = 128
sort_buffer_size        = 4M
bulk_insert_buffer_size = 16M
tmp_table_size          = 32M
max_heap_table_size     = 32M
skip-name-resolve       = 1
myisam_recover_options = BACKUP
key_buffer_size         = 128M
table_open_cache        = 400
myisam_sort_buffer_size = 512M
concurrent_insert       = 2
read_buffer_size        = 2M
read_rnd_buffer_size    = 1M
query_cache_limit               = 128K
query_cache_size                = 64M
general_log_file        = /var/log/mysql/mysql.log
log_warnings            = 2
slow_query_log_file     = /var/log/mysql/mariadb-slow.log
long_query_time = 10
log_slow_verbosity      = query_plan
log_bin                 = /var/log/mysql/mariadb-bin
log_bin_index           = /var/log/mysql/mariadb-bin.index
expire_logs_days        = 10
max_binlog_size         = 100M
default_storage_engine  = InnoDB
innodb_buffer_pool_size = 256M
innodb_log_buffer_size  = 8M
innodb_file_per_table   = 1
innodb_open_files       = 400
innodb_io_capacity      = 400
innodb_flush_method     = O_DIRECT
[galera]

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]

[isamchk]
key_buffer              = 16M
OEF

Phần này chỉ là tối ưu lại cách ghi log, nếu không có nhu cầu thì hãy bỏ qua nó.

cat > /etc/mysql/conf.d/50-server.cnf << 'OEF'
[mysqld_safe]
skip_log_error
syslog
OEF

Sau khi chỉnh sửa xong file cấu hình, bạn cần khởi động lại MariaDB để áp dụng thay đổi:

systemctl restart mariadb

Quay lại node 10.237.7.74 vào MySQL chạy lệnh CHANGE MASTER TOđể kết nối node này với Master hiện tại (cụm Master-Slave), nhớ truyền đúng thông tin đã lấy được từ MasterDB ở phần trên.

CHANGE MASTER TO
MASTER_HOST='10.237.7.71',
MASTER_USER='replicator',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mariadb-bin.000001';

Sau khi thiết lập CHANGE MASTER TO, hãy bắt đầu quá trình replication trên node của cụm Cluster bằng lệnh:

mysql -e "START SLAVE;"

Sử dụng lệnh sau để kiểm tra trạng thái replication:

shell> mysql -e "SHOW SLAVE STATUS\G;"
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 10.237.7.71
                   Master_User: replicator
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mariadb-bin.000001
           Read_Master_Log_Pos: 1197358
                Relay_Log_File: mysqld-relay-bin.000003
                 Relay_Log_Pos: 1197659
         Relay_Master_Log_File: mariadb-bin.000001
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
               Replicate_Do_DB: keystone_sw_auth_2
           Replicate_Ignore_DB:
            Replicate_Do_Table:
        Replicate_Ignore_Table:
       Replicate_Wild_Do_Table:
   Replicate_Wild_Ignore_Table:
                    Last_Errno: 0
                    Last_Error:
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 1197358
               Relay_Log_Space: 1197969
               Until_Condition: None
                Until_Log_File:
                 Until_Log_Pos: 0
            Master_SSL_Allowed: No
            Master_SSL_CA_File:
            Master_SSL_CA_Path:
               Master_SSL_Cert:
             Master_SSL_Cipher:
                Master_SSL_Key:
         Seconds_Behind_Master: 0
 Master_SSL_Verify_Server_Cert: No
                 Last_IO_Errno: 0
                 Last_IO_Error:
                Last_SQL_Errno: 0
                Last_SQL_Error:
   Replicate_Ignore_Server_Ids:
              Master_Server_Id: 1
                Master_SSL_Crl:
            Master_SSL_Crlpath:
                    Using_Gtid: No
                   Gtid_IO_Pos:
       Replicate_Do_Domain_Ids:
   Replicate_Ignore_Domain_Ids:
                 Parallel_Mode: optimistic
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Slave_DDL_Groups: 6
Slave_Non_Transactional_Groups: 2
    Slave_Transactional_Groups: 5705

Node trong cụm Cluster sẽ tiếp tục đồng bộ với Master (cụm Master-Slave). Trong thời gian này, cả hai hệ thống sẽ hoạt động song song.

Kiểm tra Seconds_Behind_Master trên cụm Cluster để đảm bảo rằng cụm Cluster không bị quá nhiều độ trễ so với Master.

Sau khi dữ liệu đã được đồng bộ đầy đủ, bạn có thể chuyển hệ thống ứng dụng từ sử dụng Master-Slave sang cụm Cluster mà không cần downtime.

Khi chắc chắn rằng mọi ứng dụng đã chuyển sang cụm Cluster, bạn có thể dừng replication trên cụm Cluster nếu không cần nữa:

mysql -e "STOP SLAVE;"

4. Kiểm tra kết quả đồng bộ.

Bạn có thể tham khảo sử dụng script dưới để thực hiện insert record và read record phục vụ cho việc kiểm tra.

#!/bin/bash

counter=1

while true; do
  # Insert a new record into the database
  mysql -u root --password='' -e "USE keystone_sw_auth_2; INSERT INTO test_table VALUES ($counter, 'Hello World $counter');"

  # Read the last inserted record and print it to the screen
  result=$(mysql -u root --password='' -e "USE keystone_sw_auth_2; SELECT * FROM test_table ORDER BY id DESC LIMIT 1;")
  echo "$result"

  # Increment the counter
  counter=$((counter + 1))

  # Wait for 1 second before the next iteration
  sleep 1
done

Sau một khi uống xong ly cà phê thì script của mình đã tạo ra được gần 6400 record. Đây là kết quả mình check tại MasterDB.

root@node71:~# mysql -u root --password='' -e "USE keystone_sw_auth_2; SELECT * FROM test_table;" | tail -n 5
6390    Hello World 6390
6391    Hello World 6391
6392    Hello World 6392
6393    Hello World 6393
6394    Hello World 6394

Và đây là kết quả mình check trên IP 10.237.7.73 của cụm mới.

root@node73:~#  mysql -u root --password='' -e "USE keystone_sw_auth_2; SELECT * FROM test_table;" | tail -n 5
6390    Hello World 6390
6391    Hello World 6391
6392    Hello World 6392
6393    Hello World 6393
6394    Hello World 6394

Tương tự thì đây là kết quả mình check trên IP 10.237.7.74 của cụm mới.

root@node74:~#  mysql -u root --password='' -e "USE keystone_sw_auth_2; SELECT * FROM test_table;" | tail -n 5
6390    Hello World 6390
6391    Hello World 6391
6392    Hello World 6392
6393    Hello World 6393
6394    Hello World 6394

Kết quả khi show status của cụm mới vẫn là 3 node bình thường.

root@node73:~# mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Enter password:
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Với phương pháp này, bạn có thể di chuyển toàn bộ dữ liệu mà không làm gián đoạn hoạt động của hệ thống.

Chúc các bạn thành công.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

4,956FansLike
256FollowersFollow
223SubscribersSubscribe
spot_img

Related Stories