Posts tagged ‘备份’

远离故障的十大原则

 

故障是运维人员永远的痛。相信每一个运维人员的KPI中都有一项:可用性。可用性高就是不出故障,各个公司对可用性和故障评级的标准都不相同,但是避免故障的方法却是殊途同归。我们怎么避免故障,沃趣科技简单列举了以下几条,与大家共勉!
1、变更要有回滚,在同样的环境测试过
2、对破坏性的操作谨慎小心
3、设置好命令提示 
4、备份并验证备份有效性
5、对生产环境存有敬畏之心
6、交接和休假最容易出故障,变更请谨慎
7、搭建报警,及时获得出错信息。搭建性能监控,了解历史,获得趋势,预测未来
8、自动切换需谨慎
9、仔细一点,偏执一点,检查,检查,再检查
10、简单即是美。

 

第1条,变更要有回滚,在同样的环境测试过。也是运维最繁琐,最苦逼的地方,所有的变更都必须有回滚的办法,在同样的环境下测试过。没有做过的东西,总是会在你意想不到的地方给你一次痛击,在阿里巴巴的这么多年运维经验告诉我们,所有没有做过的变更,出错的概率最大。所以我们需要给变更以回滚的可能,在各个步骤可能出错的情况下,考虑回滚到最初状态。优秀的运维人员对不考虑回滚的的操作都是敬而远之的。从某种意义上来说,运维是一门经验的学科,是一门试错的学科。

 

第2条,对破坏性的操作谨慎小心。破坏性的操作有哪些列?对数据库来说有:DROP Table, Drop database, truncate table, delete all data;这些操作做完了以后几乎无法考虑怎么把数据都回滚回去了。就算回滚,代价也是非常大的。你执行这样的语句非常简单,但是回滚恢复数据缺非常困难。linux的命令rm可以-r(recursive)递归的删除某一个目录,-f(force)强制删除,但是你有没有删错过文件。我们遇到过一个文件名中末尾有空格的情况,而有的同事rm -r习惯性的会在文件名后面加*,这样就成了rm -r aa *,所有当前目录的数据都被删除掉了!经过这次故障以后我们给rm做了别名:
alias rm=’rm -i’
这样在删除数据时,rm命令会提示你,是否确认删除该文件。
同样的cp和mv也可以有同样的选项:
alias cp=’cp -i’
alias mv=’mv -i’

 

第3条,设置好命令提示。让你时刻知道你在操作哪个数据库,让你知道你在哪个目录下。mysql字符客户端允许你设置提示符,默认的提示符就是一个光秃秃的mysql >,为了让你清楚的知道你当前是以哪个用户名,哪个IP(可能是localhost,127.0.0.1或者具体的物理IP),你当前操作的是哪个schema,以及当前的时间,你可以设置数据库的提示符为:prompt=”\\u@\\h : \\d \\r:\\m:\\s> “。它可以直接写在my.cnf的[mysql]下,这样你每次连上MySQL就默认显示如下:
root@127.0.0.1 : woqutech 08:24:36>
具体prompt可以设置哪些提示,你可以参考http://dev.mysql.com/doc/refman/5.6/en/mysql-commands.html中的列表
而linux命令提示符也允许你设置的。有两个地方可以设置。第一个:PS1。这个是每次shell提示你输入命令的信息,默认为:$或者#,只会提示你是超级用户还是普通用户。有经验的运维者会设置export PS1=’\n\e[1;37m[\e[m\e[1;31m\u\e[m\e[1;31m@\e[m\e[1;31m\h\e[m \e[4mpwd\e[m\e[1;37m]\e[m\e[1;36m\e[m\n\$’。这样你就可以知道你当前的目录,登录的用户名和主机信息了,示例提示符如下:
[root@woqu-lsv-01 /home/mysql]
#
你可以查看http://www.cyberciti.biz/tips/howto-linux-unix-bash-shell-setup-prompt.html获得具体的PS1设置颜色,设置各个提示内容的介绍。
第二个提示符就是PROMPT_COMMAND。这个是设置你连到具体的数据库以后标签页标题上显示的内容,Windows用户可能会用securtCRT,Mac用户可能会用iTerm2,开多个标签页的话,如果每个标签页的标题上内容一样,我们切来切去就有可能在错误的标签页上做操作,设置了这个以后,这个问题概率就会小很多。比如我们的机器上设置为PROMPT_COMMAND=’echo -ne “\033]0;${USER}@${HOSTNAME%%.*}”; echo -ne “\007″‘对应的标签页如下图

prompt_command

 

 

 

 

第4条,备份并验证备份有效性。是人总会出错,是机器总可能会有突然崩溃的那一天。怎么办-我们需要准备备份。

备份的学问很大。按照不同的纬度可以分为:冷备份和热备份;实时备份和非实时备份;物理备份和逻辑备份。

互联网企业为了提供7*24小时不间断的服务,数据库就需要有实时热备份。在主库出现问题的情况下能够由备库提供服务。备库时候有效,数据是否一致,主库出现问题的时候怎么切换都需要运维人员认真考虑。

是不是有了这些就够了列?不行,应用程序也是人写的,曾经出现过程序一不小心delete语句没有带任何条件,导致一个表中所有的数据都被删除的惨状。所以你除了实时的备份,还需要有非实时的备份,在你的数据出现逻辑错误之后能够从备份数据中恢复出来。现在很多人在研究MySQL模仿oracle的flashback功能,利用binlog来恢复数据。但是这样的话,binlog_format必须设置为row并且对于DDL操作也无法回滚。它是为快速解决部分数据被错误删除的解决方案,但是无法代替非实时备份的作用。

非实时备份有可以分为在线延时备份和离线备份。在线延时备份是搭建数据库的一定时间延迟的热备份,比如MySQL就可以搭建一个延迟一天的slave,一直保持着备库与主库的延迟在一天。可以利用pt-slave-delay工具来实现这个功能。另外,离线备份是目前大家用的比较多的,可以利用mysqldump进行逻辑备份或者xtrabackup进行物理备份。为了空间的原因和快速恢复考虑,你还可以利用xtrabackup进行增量的物理备份。

备份有了,是否就可以高枕无忧了?还是不行。你需要验证备份的有效性。没有一个备份能够保证它备份出来的数据能够100%恢复出正确的数据,特别是物理备份的概率相对来说,更低,xtrabackup备份一个月总有那么几次来大姨妈,不能给你很好的服务。所以,备份并不只是备份,它还包括备份的验证,它如果不能恢复出正确的数据,就只是浪费空间而已。备份的验证最简单的就是找一个空闲的库,来恢复出来,mysql启动以后检查部分数据。如果不需要这么严谨,对于xtrabackup来说,你至少得验证它–apply-log能够恢复上去吧?同样,备库的数据一致性也需要经常检查一下,mysql的replication并不保证100%的数据一致性,你可以去翻翻mysql statement复制的bug列表,有些数据在主备不同的环境上分别执行,数据就会不一样。可以考虑用percona的工具pt-table-checksum来检查主备不一致,用pt-table-sync来同步主备数据。

 

 

第5条,对生产环境存有敬畏之心。这应该是运维者进入行业首先需要具备的素质。但是我们还是需要把它拿出来强调一下。

有机会的话,你可以梳理一下:

  • 你的生产环境上有哪些账户,这些账户是否都确实需要登录到机器上来?这些账户即包括linux用户还包括数据库账户。
  • 你的root用户是否开放给了某些用户,这些用户安全吗?
  • 你的用户密码是否经常修改,是否加密不让具体的操作人员直接看到,密码强度时候足够,密码重试次数达到一定次数是否黑名单;
  • 你的生产环境和线下环境是否隔离,数据库是否和外网隔离?
  • 是否一些工作明明能够在开发库和测试库做,却被放到生产环境上去了。
  • 是否有专门的人负责线上应用的发布,从而避免开发人员直接接触生产环境

这些都是你避免出现csdn密码泄漏,在业界的名声一落千丈的法宝。

 

 

第6条,交接和休假最容易出故障,变更请谨慎。这个是经验之谈。我们在总结故障的情况时,发现在公司部门有变化时,工作交接(不管是休假,工作职责变化还是离职),故障的出现频率会比正常情况下多50%以上。有人说,这是因为机器或者应用是有感情的,舍不得离开的运维者。

我们不谈感情,简单的理性分析一下。公司或者部门难免会做一些调整,变化是世界上唯一不变的事情。而运维人员是一线做事情的人,部门调整或者领导的更换可能导致工作的着重点不同,做事的方式和评测的标准变了,适应过程中难免会出现一些考虑不周到的地方,出故障也是情理之中了。

而工作交接,对运维人来说,其实是一个非常费时费力的事情,你需要把所有平常做的工作都梳理清楚,甚至包括你的一些经意不经意的操作习惯,这样的话,下一个人才可能接手的下来。比如:你可能认为备库正常情况下没有访问,于是让某些并不重要的任务(一个月一次抽取部分数据到线下测试?)直接连备机IP进行操作。下一个人接手,认为备机就是备机,操作起来不会有任何问题,结果下一次任务抽取就是一个故障出来了。再举一个我们遇到了事例吧:同事A出国休假了,休假期间估计联系不上,他留了文档,并告诫说某几个库和表是比较核心和容易出问题的,没有特殊情况最好等他回来再做变更。正好,休假期间,开发人员找到同事B,要求他重置一个字段的某一位(bit),并打包票说这个bit没有用,同事B拒绝,并背上了不配合的骂名。同事A回来吓了一身冷汗,原来这个字段已经被另外一个离职的开发使用了。

所以,运维部门和运维人员对变化需要尽量放平心态;接手别人的工作要一而再,再而三的确认变更方案。请教人并不见得就是能力不行的表现;休假前最好各种可以做好的事情,最好能够准备一份文档,指明在什么情况下怎么做和联系哪些人。在别人放假的时候接手工作,“能拖则拖”,实在需要执行:必须不厌其烦的跟原运维者确认各个操作细节。 

 

 

第7条,搭建报警,及时获得出错信息。搭建性能监控,了解历史,获得趋势,预测未来。运维的最高境界不是故障来了,泰山崩于前而不惊,苍老师勾引你而抗日;而是没有故障,让故障消失在萌芽之中。请给那些默默无闻,每天想着我们的系统还存在哪些隐患,怎么解决,怎么及早发现的运维人员鼓掌。他们是最可爱的人。而他们赖以生存的工具就是报警和监控。Oracle发展了这么多年,awr和相关的性能参数都相对比较全;MySQL现在也已经迎头赶上,配套的工具越来越多。

报警可以让你及时知道系统出现了什么异常。比如slave io报警,在数据库replication异常的时候就会提醒你:IO线程出现了问题,可能是网络问题,主数据库问题等,slave sql报警会提醒你replication的SQL线程出现了问题,可能是主备不一致,slave被停掉了,存储过程在备机有异常或者其他问题。这样你收到报警就可以及时跟进,而不至于主备长时间不一致,主库坏掉了想要切换到备库的时候却不能切换。

性能监控可以让你了解系统的历史性能信息。分析故障发生时的各种现象,确认故障的真正原因;了解变化趋势,发现故障的苗头,及早优化和调整。比如你如果使用了PCI-E的Flash卡,你可以监控logical_written_bytes,logical_read_bytes,physical_written_bytes,physical_read_bytes以便获得flash卡的每秒的逻辑读写和物理读写字节数。对于MySQL你可以监控Com_delete+Com_delete_multi, Com_insert+Com_insert_select,Com_update+Com_update_multi,Com_select来获得每秒的MySQL DML删除,插入,更新和查询的次数。

报警和性能监控其实不不完全独立的,很多性能的监控项也可以报警出来。比如linux的iostat中的await_time可以作为性能监控采集起来获得系统IO响应时间的变化曲线,当该值达到20以上的时候,也可以报警出来,让运维人员跟进是磁盘阵列中坏了一块,还是异常的数据拷贝影响了系统的IO性能等。

nagios和cacti是目前MySQL领域使用最广泛的报警和性能展示系统。percona最新推出percona-monitor-plugins(http://www.percona.com/software/percona-monitoring-plugins)就是基于他们俩的。

 

 

第8条:自动切换需谨慎。现在数据库的HA很多都是进行自动切换的,这样运维人员深夜起来手工切换到备库的机会就会少很多。切换也会快速很多。但是,它带来的副作用也不容忽视。

现在业界使用的HA软件非常多,heartbeat由于很多SA兼作DBA的运维比较熟悉,在MySQL自动切换也是不少的。一般来说,它会通过mysqladmin ping来探测MySQL是否存活,如果发现异常,那么他就会切换VIP和MySQL资源到备库。但是此时备库的数据延迟是否为0,主库crash之后binlog的数据是否全部都同步到备库上去了,备库的read_only是否关闭,这些heartbeat都不管。我们想象一下,主库上应用提交了一笔订单,结果发生了切换,这笔订单没有同步到备库上,卖家也就损失了一个销售单,对客户,对公司都是非常大的影响。

当然,自动切换也不能全盘否定,它能够更快速的将应用切换到新的热备份备库上,应用的不可用时间大大缩短。只是我们要好好利用这一把双刃剑,仔细评估它的影响,降低或者去除副作用,让它为我们服务。

 

 

第9条,仔细一点,偏执一点,检查,检查,再检查。之前我跟一个资深的运维学习线上操作的时候,觉得这家伙有点变态,他在做一个变更的时候,会先提前一两周发送邮件并电话手机的通知相关人;在测试机上写好脚本,召集大家review操作步骤和脚本;测试完成以后拷贝到生产环境;登录对应机器,“打开,关闭,打开,关闭”该脚本;跟相关人员再次确认执行的操作,顺序,时间点,可能的影响和回滚是否都准备好了;执行前还要退出这个机器,然后再登录进去,“打开,关闭”脚本;最后才在后台运行脚本,在另外一个窗口登录着,随时ps和查看结果输出。期间姿势端正,呼吸急促而均匀,眼神凝重。操作的人不觉得累,倒是一边学习的人很累。

当我做到一定程度,我也开始这样了。医学上,这种好像叫做强迫症。唉…,提前通知会让大家都有准备,也避免了临时相关人员过来说这个操作和其他操作有依赖需要调整操作时间的问题; 召集大家review步骤和脚本是为了让大家一起来看看整个过程中还有哪些依赖没有考虑到或者哪些细节没有注意到,三个臭皮匠顶一个诸葛亮在运维来说是金科玉律;“打开,关闭,打开,关闭”是为了一再确认脚本拷贝过来是否正确,目录时候正确,思考在测试环境运行和在生产环境运行有什么不一样的;退出再登录机器是为了确认我登录的机器确实没有错;在后台运行是担心网络突然中断,我的脚本运行到一半怎么办;调整呼吸和端正姿势是为了对这个操作的敬重,对自己工作和运维工作的尊重。

以MySQL 使用flash卡为例吧。flash算是一个比较新的事务,提供的IO比普通磁盘是几个数量级的提升。要想在生产环境使用,首先我们需要对他进行详尽的评估和破坏性测试,设置各种参数,考虑他们在各种场景下使用的配置;24小时不间断的进行半个月读写操作,中途突然掉电;高并发,高吞吐量下的测试;温度湿度极限测试;预留空间释放测试等等。然后我们会尝试在测试库上部署试用,收集和修改各个配置已达到最稳定,最高性能的配置;运行稳定以后我们才考虑在线上备库使用,并且主备要求异构;适当的时机切换为使用新的flahs卡为主库,万一出现了问题,还可以切换回原主机。

这里也跟大家简单介绍一下screen命令,这个命令会在服务器段开启一个session,就算你的网络断掉了,你的脚本也会自动在后台运行。screen -S woqutech可以开启一个woqutech命令的后台session;如果你的网络断掉了,你可以用screen -dr woqutech连上之前的session继续进行操作。IBM的文档库中有一个非常靠谱的文档:http://www.ibm.com/developerworks/cn/linux/l-cn-screen/

 

第10条,简单即是美。最后一条有点禅的意境了。它和Unix的思想不谋而合。我们总是面临着各种诱惑:新的系统架构,新的更智能的命令和工具,最新的硬件平台,功能更全的HA软件等。他们总是以各种各样的方式吸引我们,most exciting,unbelievable,让你欲罢不能。你可以在线下安装,测试,怎么搞都行。但是如果想要在生产环境下使用起来,那就得经过非常详细,非常漫长,各种方式验证其稳定性的过程。

能够使用系统内置命令的话,就不用考虑其他要专门下载安装的软件了;脚本本身就能完成的功能,就没有必要专门找一个功能丰富的软件来做;linux本身自带的字符界面比那些复杂的图形界面要简洁方便;MySQL的一些分区,生僻函数,没有必要的话不要使用。

 

最后祝大家运维的运维工作一帆风顺,多福多寿,不出故障。

参考:http://feedproxy.google.com/~r/iheavy/~3/sRnyFPA0R9E/

非常规change master

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.