Posts tagged ‘xtrabackup’

xtrabackup Bad file descriptor问题解决

一直使用xtrabackup来备份MySQL,之前也没有出过特别的问题,但是在备份我们的一个库的时候,出现了:Bad file descriptor的错误
具体错误类似如下:
InnoDB: Operating system error number 9 in a file operation.
InnoDB: Error number 9 means ‘Bad file descriptor’.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
InnoDB: File operation call: ‘close’.
InnoDB: Cannot continue operation.

仔细检查,发现用户的权限有点问题;修改好了以后,再次备份,还是有问题。
然后看看这个机器跟其他机器的不同点:他的数据文件是链接到另外的mount点的,但是这个为什么会影响xtrabackup出错真是搞不懂。
有问题找google,还好搜到一篇好文章,有人也碰到了这个问题。
https://bugs.launchpad.net/percona-xtrabackup/+bug/568087

问题一样,还有人解决了,一直追到:http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/133
仔细一看,这个版本是release版本之后的修改,也就是说,现成的rpm包我们是没有办法用了。
只好自己编译。
好吧,那就自己编译,还好之前在solaris上编译有经验。
这里也简单记录一下编译的一些步骤:
1、133版 http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/133 下只有xtrabackup.c下载,我们可以自己到http://launchpad.net/percona-xtrabackup/release-1.2/1.2/+download/xtrabackup-1.2.tar.gz下载1.2版的源码。并把里面的xtrabackup.c替换掉。
2、xtrabackup-1.2/utils对应的目录里面有build51tree.sh, buildtree.sh分别是在linux下编译5.0和5.1版xtrabackup的脚本
3、正常的话,按照xtrabackup-1.2/Makefile里面的默认的配置是MySQL Plugin并使用XTRADB。而我并不想这样,所以我注释掉了DEFS+=  -DXTRADB_BASED和#MySQL Plugin下面的那些编译项。但是编译还是报错,查看了之前solaris编译时的注意实现发现要注释掉#MySQL 5.1下的第二个INNODBOBJS=。不知道为什么Makefile这边有两个这样的INNODBOBJS=,管它,注释掉第二个以后编译就成功。
用新版本备份,备份成功。

其实后面看了一下这个版本修改的代码:
2326
2326

2327
2327
/* close */
2328
2328
printf(”        …done\n”);
2329

os_file_close(src_file);

2329
if (!node->open) {

2330
os_file_close(src_file);

2331
}
2330
2332
os_file_close(dst_file);
2331
2333
ut_free(buf2);
2332
2334
return(FALSE);
2333
2335
error:
2334

if (src_file != -1)

2336
if (src_file != -1 && !node->open)
2335
2337
os_file_close(src_file);
2336
2338
if (dst_file != -1)
2337
2339
os_file_close(dst_file);
就那么几行,是因为没有判断节点是否还打开,结果导致出错,唉,程序的异常处理确实需要比程序本身的逻辑复杂很多啊。
不过还是没有想明白为什么这台机器就有问题,其他的都没有问题。

may your success.

xtrabackup 多实例MySQL备份

花了两个晚上,10来个小时,来测试如何让xtrabackup在多实例的MySQL上成功备份出来,最终找到了一个办法:–defaults-file=”fake/my.cnf.1″,也就是传递一个假的mysql配置文件,让它读取对应的实例数据,备份出来。这样,对每个实例做一个假的mysql配置文件,传给它让它备份出来。

其实我想到的第一个办法就是这个办法。但是作为程序员出身的我,有点追求完美的程序员,始终感觉这种方法太臭了。于是我开始尝试:
1、修改innobackupex-1.5.1的perl文件。
发现innobackupex-1.5.1脚本里面mysqld是写死的,也就是说它就只支持一个实例。好吧,那我就把mysqld全部修改成参数,然后通过参数传递进去(顺便再次温习了一下perl的GetOptions函数,呵呵)。这样总行把?不行。测试的结果报错,说
fatal error: OR no ‘datadir’ option in group ‘mysqld1’ in MySQL options
对应的代码如下:
if (!exists $config{$group}) {
# no group
print STDERR “$prefix fatal error: no ‘$group’ group in MySQL options\n”;
print STDERR “$prefix fatal error: OR no ‘datadir’ option in group ‘$group’ in MySQL options\n”;
exit(1);
}
而检查了以后发现是另外一个问题:
xtrabackup: Error: Please set parameter ‘datadir’
xtrabackup报错了,恩,只好仔细看看文件看看脚本了,发现read_config_file函数里面这么说的:
if ($option_defaults_file) {
$options = $options . ” –defaults-file=\”$option_defaults_file\” “;
}

$options = $options . “–print-param”;

# read file to an array, one line per element
#file_to_array($filename, \@lines);
$cmdline = “$option_ibbackup_binary $options”;
@lines = $cmdline;
大家特别注意:”$option_ibbackup_binary $options”,翻译成白话文就是xtrabackup [–defaults-file=#] –print-param,也就是说innobackupex-1.5.1它自己没有处理mysql配置文件的地方,他让xtrabackup去处理,它只管拿现成的。他把这些东西通通放到hash map里面,通过get_option从hash里面获得datadir,innodb_data_home_dir等一系列信息。而xtrabackup解析文件的时候就报错,找不到mysqld组,所以,修改innobackupex-1.5.1是不可行的。

2、如果xtrabackup报错,那么修改xtrabackup的源文件来让它不报错可不可以列?
修改源码的事情比较不靠谱,就算我修改了,并且运行良好,xtrabackup以后的更新和bug修复我就赶不上了。先看看把,也许修改起来简单的。一看,虽然就一个xtrabackup.c文件,但是没有找到比较好下手的地方。罢了罢了,回归到骗人的把戏上吧。

3、骗人的把戏
查看xtrabackup的时候,倒是发现可以在my.cnf上配置xtrabackup的组,把备份的一些参数信息这样传给它。现在就有两个办法,
a、在mysql配置文件中放一个xtrabackup的组,把各个实例的配置信息轮询的更新到组里面,让xtrabackup备份
b、针对每个实例新建一个假的mysql配置文件,让xtrabackup的备份每次读取不同的文件来备份
呵呵,当然是第二个办法好了,于是测试开始,妈的,一直出错,传递的–default-file文件给它,它就是不读,倔强的报错。最后竟然发现是–defaults-file少了一个s,悲剧。好,这个搞定以后就没有什么问题了。建立两个假的mysql配置文件,让它备份把。
[pickup.lichun@alibaba-26841 xtrabackup-1.2]$ xtrabackup –defaults-file=’/tmp/my.cnf’ –print-param
# This MySQL options file was generated by XtraBackup.
[mysqld]
datadir = “/data/mysqldata1/mydata”
tmpdir = “/data/mysqldata1/tmpdir/”
innodb_data_home_dir = “/data/mysqldata1/innodb_ts”
innodb_data_file_path = “ibdata1:256M:autoextend”
innodb_log_group_home_dir = “/data/mysqldata1/innodb_log”
innodb_log_files_in_group = 2
innodb_log_file_size = 536870912

may your success.

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.