eshop MySQL数据库主备机数据xtrabackup同步数据

今天需要再次用到xtrabackup来备份和恢复数据。找了半天终于把以前写的一个文档找到了。保存在blog中。以防丢失。xtrabackup更换为 xtrabackup-1.2-22.rhel5.x86_64.rpm也已经测试通过

一.迁移目的
目前ITBU eshop MySQL数据库有64台数据库服务器。两两互备作为双master结构相互备份。但是由于应用方使用了MySQL的uuid函数,导致两两互备的mysql服务器之间的数据不一致。这样两个数据库切换将导致用户数据的丢失。
4月底,应用方修改了uuid的问题,避免的新的数据不一致问题。接下来就只有数据库中已有的数据不一致问题了。
MySQL数据库,由于主备之间已经切换过多次,目前一部分数据已经无法找回。跟应用沟通后,确定以目前主库的数据为准,将主库的数据同步到备库。备库的数据备份到本机。保存一个月。

二.迁移要求
1、迁移过程中要求不影响应用,也就是说eshop数据库服务不能停止。
2、迁移完成后主备机数据保持一致。

三.迁移方案
这里由于管理维护的必要,我们假设主备机我们都是以root登录。xtrabackup在MySQL中的权限为:
root@127.0.0.1 : (none) 20:57:24> show grants for ‘xtrabackup’@’localhost’\G
*************************** 1. row ***************************
Grants for xtrabackup@localhost: GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ‘xtrabackup’@’localhost’ IDENTIFIED BY PASSWORD ‘*BF9F4C1B8BC37C75BBF482C8037EC944555D371A’
*************************** 2. row ***************************
Grants for xtrabackup@localhost: GRANT INSERT, CREATE, DROP ON mysql.ibbackup_binlog_marker TO ‘xtrabackup’@’localhost’
2 rows in set (0.00 sec)

3.1.备份/恢复工具选择
由于迁移过程中不能够停止数据库服务,数据库备份必须选择热备份。两种选择mysqldump的逻辑热备以及xtrabackup的物理热备。为了恢复时间考虑,决定采用xtrabackup。

3.2.备机备份数据的选择
eshop网店目前有两个存储,他们目前都在老聚园路。一个存储暂时没有上电,另外一个存储空间所剩不多。目前每台eshop备机平均为130G的数据,一共32台,需要4T多的存储空间。而如果把eshop的32套备机数据放到存储上,对存储空间和网络的消耗都是巨大的。
最终,我们选择在备机存储本机的老数据。而不做另外拷贝。
附件eshop_backup_slave_data_20100422.sh是备份备机数据的脚本

3.3.主备机数据拷贝方案选择
主机备份生成的数据大小约为130G左右,正常的话我们可以通过scp来拷贝,但是scp拷贝要么需要手工输入密码,要么需要打通ssh隧道。如果用脚本来操作的话,只能打通主备机之间的ssh隧道。另外scp不能够限速。数据拷贝量大的话可能引起网络堵塞。最后,考虑采用rsync拷贝数据,它不仅能够限速。并且可以在主机上启动rsync –daemon,不用打通隧道(需要注意在拷贝完数据以后停止rsync后台进程)
附件eshop_master_rsync_daemon_local.sh和eshop_master_rsync_daemon_remote.sh是用于在eshop的master机器上添加rsync daemon的脚本。rsyncd.conf是拷贝到主机的rsync配置文件。

3.4.主机数据库备份方案
eshop主备机每天5:30的时候都会有一个计划任务判断当前主机是否是备机。如果是备机则利用xtrabackup(innobackupex-1.5.1版本为0.7)生成物理备份。这里我们只需要简单修改一下备份脚本就可以在主机上也生成备份(注意主机备机完之后需要把该脚本修改回来)。直接利用
innobackupex-1.5.1 –slave-info –no-timestamp –user=”${XTRA_BACKUP_USER}” —password=”${XTRA_BACKUP_PASSWORD}” ${XTRA_BACKUP_DIR}
生成备份。这里需要注意xtrabackup用户的权限。
附件eshop_master_backup_local.sh是用于主机xtrabackup备份数据库的脚本。backup_mysql.sh是需要拷贝到主机上执行的脚本

3.5.备机数据恢复方案
主机数据拷贝到备机以后,由于是xtrabackup备份出来的,所以也要用它来恢复。注意,在恢复备机数据库数据前需要将备机数据库MySQL先停掉。原有的MySQL数据目录需要mv到另外的位置。并根据需要新建好数据库需要的目录,为备份数据拷贝到对应目录准备好环境。
xtrabackup需要先生成logfile,然后将产生的相关数据拷贝到具体的数据文件目录中。需要需要执行两次。
■第一次利用:
innobackupex-1.5.1 —apply-log /home/mysql/fs3/master_bak_data/eshop_alsmy_eshop13b_2010_04_27/
应用备份期间变化的数据和生成ib_logfile。这里需要注意将该命令输出的结果记下来。后面主备机双maser复制环境的搭建需要利用到这里的”Last MySQL binlog file position”信息
■第二次利用:
innobackupex-1.5.1 —copy-back /home/mysql/fs3/master_bak_data/eshop_alsmy_eshop13b_2010_04_27/
将生成好的数据拷贝到/etc/my.cnf指定的datadir和innodb_data_home_dir等对应目录中。

3.6.备机数据库启动和清理
备机数据库数据恢复以后,需要将数据库的目录owner修改一下。chown -R mysql:mysql ${MYSQL_DATA_DIR}。否则MySQL启动会出错。
启动MySQL数据库,正常的话启动是没有问题的。如果出现问题,需要查看MySQL的错误日志,并根据不同的错误类型处理。
启动成功以后,MySQL数据库里面的数据都是主机的数据。我们需要根据不同的情况对它进行修改。(这里最好SET SQL_LOG_BIN=0避免把一些数据记录到binlog中,从而复制到主机去了。)eshop这边因为复制帐号是replicator@’${SLAVE}’基于备机ip地址的,所以需要修改为基于主机的复制帐号。这样备机到主机的复制才能搭建起来。
root@127.0.0.1 : (none) 16:13:06> show grants for replicator@’172.18.94.25′;
+—————————————————————————————————————————————————————————–+
| Grants for replicator@172.18.94.25 |
+—————————————————————————————————————————————————————————–+
| GRANT SELECT, RELOAD, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘replicator’@’172.18.94.25’ IDENTIFIED BY PASSWORD ‘*3836CCEA58805DB4CE7093BF6170F7A6027CDD86’ |
+—————————————————————————————————————————————————————————–+
1 row in set (0.00 sec)

root@127.0.0.1 : (none) 16:14:20> GRANT SELECT, RELOAD, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘replicator’@’172.18.94.26’ IDENTIFIED BY ‘xlia9810pal’;
Query OK, 0 rows affected (0.00 sec)

root@127.0.0.1 : (none) 21:21:02> drop user replicator@’172.18.94.25′;
Query OK, 0 rows affected (0.03 sec)

root@127.0.0.1 : (none) 16:14:44> flush privileges;
Query OK, 0 rows affected (0.00 sec)
附件eshop_slave_sync_master_data.sh是用来恢复备机数据库和清理数据的脚本。

3.7.主备机双master复制环境搭建
3.7.1.搭建备机到主机的复制
由于备机是从主机导入的数据,并且备机没有应用访问,binlog没有变化。我们首先搭建备机到主机的复制。首先确定备机的binlog位置。利用show master status可以查到。
root@127.0.0.1 : (none) 21:37:38> show master status;
+——————+———–+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———–+————–+——————+
| mysql-bin.000001 | 98 | | |
+——————+———–+————–+——————+
1 row in set (0.00 sec)
如无意外,都应该是第一个文件的最开始位置。
修改主机的master位置:
Stop slave;
CHANGE MASTER TO MASTER_HOST=’172.18.94.25′, MASTER_USER=’replicator’, MASTER_PASSWORD=’xlia9810pal’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=98;
Start slave;
检查是否复制搭建成功:
Show slave status\G
如果Slave_IO_Running,Slave_SQL_Running其中一个为No。需要检查MySQL的错误日志。一般可能有两种错误:
■备机的授权有问题
■备机的binlog位置有问题
附件eshop_master_change_master.sh为配置备机到主机的复制环境的脚本。

3.7.2.搭建主机到备机的复制
保证备机到主机的复制正确以后,我们就可以搭建主机到备机的复制了。
备机从主机的哪个位置开始复制很重要,这个位置是从 备机数据恢复方案 中得到的。在apply-log的时候,有一行文字很重要:
InnoDB: Last MySQL binlog file position 0 651339984, file name ./mysql-bin.001604
这里记录了主机的复制开始文件和开始位置(这里就是mysql-bin.001604,651339984)。那么我们搭建主机到备机的复制就很简单了:
Stop slave;
CHANGE MASTER TO MASTER_HOST=’172.18.94.26′, MASTER_USER=’replicator’, MASTER_PASSWORD=’xlia9810pal’, MASTER_LOG_FILE=’mysql-bin.001604′, MASTER_LOG_POS=651339984;
Start slave;
检查是否复制搭建成功:
Show slave status\G
如果Slave_IO_Running,Slave_SQL_Running其中一个为No。需要检查MySQL的错误日志。
这里由于备份的时间已经经过了这么长的时间,主机到备机的复制肯定有延迟,静静的等待主备机的复制就可以了。
附件eshop_slave_change_master.sh为配置主机到备机的复制环境的脚本。

四.附件介绍
附件中的各个脚本介绍如下:
■附件eshop_backup_slave_data_20100422.sh是备份备机数据的脚本
■附件eshop_master_backup_local.sh是用于主机xtrabackup备份数据库的脚本。backup_mysql.sh是需要拷贝到主机上执行的脚本
■附件eshop_master_rsync_daemon_local.sh和eshop_master_rsync_daemon_remote.sh是用于在eshop的master机器上添加rsync daemon的脚本。rsyncd.conf是拷贝到主机的rsync配置文件。
■附件eshop_slave_sync_master_data.sh是用来恢复备机数据库和清理数据的脚本。
■附件eshop_master_change_master.sh为配置备机到主机的复制环境的脚本。
■附件eshop_slave_change_master.sh为配置主机到备机的复制环境的脚本。

may you success.

One Comment

  1. linuxworkroom说道:

    兄弟 附件脚本在哪里下载

Leave a Reply