June 16, 2015

phục hồi mysql replication break

Giới thiệu

Khi mysql replication bị hỏng thì có rất nhiều cách để xử lý nhưng có một cách tốt hơn cả là có thể bê nguyên toàn bộ data của master về slave ngay lập tức và tái lập replication bắt đầu tại thời điểm chuyển toàn bộ data sang. Rất may, percona xtrabackup có thể được tận dụng để làm việc đó.

Một số điểm chú ý

  • Bạn không cần phải down master nhưng vẫn cần phải down slave. Thời gian slave down cũng không quá lâu nên nói chung là giải pháp này thực hiện online được ( nếu table là innodb hoàn toàn )
  • Bạn có thể sửa hầu như mọi lỗi khiến replication bị hỏng mà không cần biết lỗi đó là gì.
  • Thời gian thực hiên toàn bộ quá trình phục hồi được đo bằng = thời gian backup master + rsync backup sang slave + thời gian restore trên slave. Tốc độ backup và restore của percona xtrabackup khá cao vì có thể tận dụng khả năng xử lý đa luồng của CPU để thực hiện song song. Thường thì master và slave kết nối qua LAN nên tốc độ rsync cũng không thể quá thấp được. Vấn đề còn lại chỉ là độ lớn của data. Percona xtrabackup có hỗ trợ nén data nhưng khi đó lại phụ trội thời gian nén và xả nén. Tôi thì chưa sử dụng giải pháp này cho các data quá lớn nên chưa thấy tác động về thời gian.
  • Percona xtrabackup là online backup. Nhưng chỉ áp dụng được với innodb table. Với các myisam table thì xtrabackup cần phải lock tables một chút. Do đó, bạn cần cân nhắc sử dụng khi có table myisam.
  • Tôi đã áp dụng giải pháp này với mysql replication GTID và non-GTID thành công. Với các cơ sở dữ liệu khác như mariadb, percona, tôi chưa sử dụng bao giờ.
  • Percona xtrabackup phải cùng được cài đặt trên cả master và slave.
  • Master phải đủ không gian disk để chứa bản backup (Một bản backup không nén có dung lượng tương đương với data dir của master). Điều tương tự với slave. Nếu điều kiện này không đảm bảo thì bạn sẽ không thể tạo ra được bản backup trên master cũng như không thể chứa được backup rsync về trên slave. Một giải pháp cho vấn đề này là sử dụng một storage rồi mount storage đó lên cả master và slave.
  • Mysql replication trong bài viết này sử dụng GTID. Trường hợp non-GTID bạn có thể làm tương tự.

Thực hiện

Cài đặt percona xtrabackup trên hai server
Trên master và slave
wget http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm

sudo rpm -ivh percona-release-0.1-3.noarch.rpm

sudo yum install percona-xtrabackup
Backup trên master
sudo innobackupex  --user=root --password=<passwd of root>  --parallel=12 /data/backup/mysql/
Bạn không nên đặt giá trị parallel vượt quá tổng số core của CPU mà bạn có.
Kết quả của câu lệnh trên là: Folder 2015-06-11_14-38-08/ được tạo ra. Tên folder có dạng timestamp rất tiện lợi cho lưu trữ. Trong folder đó có một file rất quan trọng là xtrabackup_binlog_info
cat xtrabackup_binlog_info

mysql-bin.000092        63416014        ead3ffdd-0684-11e4-b2b3-00a0d1ea853c:1-8788345
Thông tin tương tự có thể tìm thấy trong output của câu lệnh backup
innobackupex: MySQL binlog position: filename 'mysql-bin.000092', position 63416014, GTID of the last change 'ead3ffdd-0684-11e4-b2b3-00a0d1ea853c:1-8788345'
Vì mysql replication sử dụng GTID nên thông tin binlog có transaction id. Nếu sử dụng mysql replication non-GTID, bạn sẽ chỉ tìm thấy có log file và log pos trong xtrabackup_binlog_info
Rsync sang slave
sudo rsync -avzP 2015-06-11_14-38-08   test@192.168.3.100:/home/test
Apply backup trên slave
sudo innobackupex  --use-memory=4G --apply-log /home/test/2015-06-11_14-38-08/
Hai file ib_logfile0 và ib_logfile1 sẽ được tạo ra trong thư mục backup
Restore trên slave
Tắt slave - Đến thời điểm này slave mới bị down
sudo service mysqld stop
Backup master.info trong datadir của slave
sudo cp master.info ~
Xóa nội dung trong datadir của slave
sudo rm -rf /var/lib/mysql/*
Sau đó restore
sudo innobackupex --copy-back --parallel=12  /home/test/2015-06-11_14-38-08/
Gán lại quyền:
sudo chown -R mysql:mysql /var/lib/mysql/
Khởi động slave
sudo service mysqld start

mysql> SET GLOBAL gtid_purged="ead3ffdd-0684-11e4-b2b3-00a0d1ea853c:1-8788345";
Giá trị truyền vào gtid_purged lấy từ xtrabackup_binlog_info
mysql> CHANGE MASTER TO
MASTER_HOST="192.168.3.99", 
MASTER_PORT=3306, 
MASTER_USER="<master_user>", 
MASTER_PASSWORD="<master_passwd>", 
MASTER_AUTO_POSITION = 1;
Trường hợp mysql replication non-GTID, bạn không cần set global gtid_purged chỉ cần change master to dùng thông tin kết nối trong master.info và thông tin log file, log pos trong xtrabackup_binlog_info để tái lập replication.
mysql> START SLAVE;
Kết thúc bài viết. Hi vọng bài viết giúp ích cho các bạn khi xử lý các mysql replication break.
Nguồn tham khảo:

0 comments:

Post a Comment