Mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份的数据库中。实现mysql数据库的热备份。
要想实现双机的热备，首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都高于3.2。还有一个基本的原则就是作为从数据库的数据版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。
当然要实现mysql双机热备，除了mysql本身自带的REPLICATION功能可以实现外，也可以用Heartbeat这个开源软件来实现。不过本文主要还是讲如何用mysql自带的REPLICATION来实现mysql双机热备的功能。
1. 准备服务器
由于Mysql不同版本之间的（二进制日志）binlog格式可能会不太一样，因此最好的搭配组合是主（Master）服务器的Mysql版本和从（Slave）服务器版本相同或者更低，主服务器的版本肯定不能高于从服务器版本。
本次我用于测试的两台服务器版本都是Mysql-5.5.17。
2. Mysql 建立主－从服务器双机热备配置步骤
2.1环境描述
A服务器（主服务器Master）：59.151.15.36
B服务器（从服务器Slave）：218.206.70.146
主从服务器的Mysql版本皆为5.5.17
Linux环境下
将主服务器需要同步的数据库内容进行备份一份，上传到从服务器上，保证始初时两服务器中数据库内容一致。
不过这里说明下，由于我是利用Mysql在安装后就有的数据库test进行测试的，所以两台服务器里面是没有建立表的，只不分别在test里面建立了同样的一张空表tb_mobile
Sql语句如下：
mysql>create table tb_mobile( mobile VARCHAR(20) comment'手机号码', time timestamp DEFAULT now() comment'时间' )
2.2 主服务器Master配置
2.2.1 创建同步用户
进入mysql *** 作界面，在主服务器上为从服务器建立一个连接帐户，该帐户必须授予REPLICATION SLAVE权限。因为从mysql版本3.2以后就可以通过REPLICATION对其进行双机热备的功能 *** 作。
*** 作指令如下：
mysql>grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456'
mysql>flush privileges
创建好同步连接帐户后，我们可以通过在从服务器（Slave）上用replicat帐户对主服务器（Master）数据库进行访问下，看下是否能连接成功。
在从服务器（Slave）上输入如下指令：
[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456
如果出现下面的结果，则表示能登录成功，说明可以对这两台服务器进行双机热备进行 *** 作。
2.2.2 修改mysql配置文件
如果上面的准备工作做好，那边我们就可以进行对mysql配置文件进行修改了，首先找到mysql配置所有在目录，一般在安装好mysql服务后，都会将配置文件复制一一份出来放到/ect目录下面，并且配置文件命名为：my.cnf。即配置文件准确目录为/etc/my.cnf
(Linux下用rpm包安装的MySQL是不会安装/etc/my.cnf文件的，
至于为什么没有这个文件而MySQL却也能正常启动和作用，在点有两个说法，
第一种说法，my.cnf只是MySQL启动时的一个参数文件，可以没有它，这时MySQL会用内置的默认参数启动，
第二种说法，MySQL在启动时自动使用/usr/share/mysql目录下的my-medium.cnf文件，这种说法仅限于rpm包安装的MySQL，
解决方法，只需要复制一个/usr/share/mysql目录下的my-medium.cnf文件到/etc目录，并改名为my.cnf即可。)
找到配置文件my.cnf打开后，在[mysqld]下修改即可：
[mysqld]
server-id = 1
log-bin=mysql-bin//其中这两行是本来就有的，可以不用动，添加下面两行即可
binlog-do-db = test
binlog-ignore-db = mysql
2.2.3 重启mysql服务
修改完配置文件后，保存后，重启一下mysql服务，如果成功则没问题。
2.2.4 查看主服务器状态
进入mysql服务后，可通过指令查看Master状态，输入如下指令：
注意看里面的参数，特别前面两个File和Position，在从服务器（Slave）配置主从关系会有用到的。
注：这里使用了锁表，目的是为了产生环境中不让进新的数据，好让从服务器定位同步位置，初次同步完成后，记得解锁。
2.3 从服务器Slave配置
2.3.1修改配置文件
因为这里面是以主－从方式实现mysql双机热备的，所以在从服务器就不用在建立同步帐户了，直接打开配置文件my.cnf进行修改即可，道理还是同修改主服务器上的一样，只不过需要修改的参数不一样而已。如下：
[mysqld]
server-id = 2
log-bin=mysql-bin
replicate-do-db = test
replicate-ignore-db = mysql,information_schema,performance_schema
2.3.2重启mysql服务
修改完配置文件后，保存后，重启一下mysql服务，如果成功则没问题。
2.3.3用change mster 语句指定同步位置
这步是最关键的一步了，在进入mysql *** 作界面后，输入如下指令：
mysql>stop slave //先停步slave服务线程，这个是很重要的，如果不这样做会造成以下 *** 作不成功。
mysql>change master to
>master_host='59.151.15.36',master_user='replicate',master_password='123456',
>master_log_file=' mysql-bin.000016 ',master_log_pos=107
注：master_log_file, master_log_pos由主服务器（Master）查出的状态值中确定。也就是刚刚叫注意的。master_log_file对应File, master_log_pos对应Position。Mysql 5.x以上版本已经不支持在配置文件中指定主服务器相关选项。
遇到的问题，如果按上面步骤之后还出现如下情况：
则要重新设置slave。指令如下
mysql>stop slave
mysql>reset slave
之后停止slave线程重新开始。成功后，则可以开启slave线程了。
mysql>start slave
2.3.4查看从服务器（Slave）状态
用如下指令进行查看
mysql>show slave status\G
查看下面两项值均为Yes，即表示设置从服务器成功。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
2.4 测试同步
之前开始已经说过了在数据库test只有一个表tb_mobile没有数据，我们可以先查看下两服务器的数据库是否有数据：
Master:59.151.15.36
Slave:218.206.70.146
好了，现在可以在Master服务器中插入数据看下是否能同步。
Master:59.151.15.36
Slave:218.206.70.146
可以从上面两个截图上看出，在Master服务器上进行插入的数据在Slave服务器可以查到，这就表示双机热备配置成功了。
3. Mysql 建立主－主服务器双机热备配置步骤
服务器还是用回现在这两台服务器
3.1创建同步用户
同时在主从服务器建立一个连接帐户，该帐户必须授予REPLIATION SLAVE权限。这里因为服务器A和服务器B互为主从，所以都要分别建立一个同步用户。
服务器A：
mysql>grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456'
mysql>flush privileges
服务器B：
mysql>grant replication slave on *.* to 'replicate'@'59.151.15.36' identified by '123456'
mysql>flush privileges
3.2修改配置文件my.cnf
服务器A
[mysqld]
server-id = 1
log-bin=mysql-bin
binlog-do-db = test
binlog-ignore-db = mysql
#主－主形式需要多添加的部分
log-slave-updates
sync_binlog = 1
auto_increment_offset = 1
auto_increment_increment = 2
replicate-do-db = test
replicate-ignore-db = mysql,information_schema
服务器B：
[mysqld]
server-id = 2
log-bin=mysql-bin
master-slave need
replicate-do-db = test
replicate-ignore-db = mysql,information_schema,performance_schema
#主－主形式需要多添加的部分
binlog-do-db = test
binlog-ignore-db = mysql
log-slave-updates
sync_binlog = 1
auto_increment_offset = 2
auto_increment_increment = 2
3.3分别重启A服务器和B服务器上的mysql服务
重启服务器方式和上面的一样，这里就不做讲解了。
3.4分别查A服务器和B服务器作为主服务器的状态
服务器A：
服务器B：
3.5分别在A服务器和B服务器上用change master to 指定同步位置
服务器A：
mysql>change master to
>master_host='218.206.70.146',master_user='replicate',master_password='123456',
>master_log_file=' mysql-bin.000011 ',master_log_pos=497
服务器B：
mysql>change master to
>master_host='59.151.15.36',master_user='replicate',master_password='123456',
>master_log_file=' mysql-bin.000016 ',master_log_pos=107
3.6 分别在A和B服务器上重启从服务线程
mysql>start slave
3.7 分别在A和B服务器上查看从服务器状态
mysql>show slave status\G
查看下面两项值均为Yes，即表示设置从服务器成功。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
3.8 测试主－主同步例子
测试服务器A：
在服务器A上插入一条语句如下图所示：
之后在服务器B上查看是否同步如下图所示：
测试服务器B：
在服务器B上插入一条语句如下图所示：
然后在从服务器A上查看是否有同步数据如下图所示：
最后从结果可以看出主－主形式的双机热备是能成功实现的。
4. 配置参数说明
Server-id
ID值唯一的标识了复制群集中的主从服务器，因此它们必须各不相同。Master_id必须为1到232－1之间的一个正整数值，slave_id值必须为2到232－1之间的一个正整数值。
Log-bin
表示打开binlog，打开该选项才可以通过I/O写到Slave的relay-log，也是可以进行replication的前提。
Binlog-do-db
表示需要记录二进制日志的数据库。如果有多个数据可以用逗号分隔，或者使用多个binlog-do-dg选项。
Binglog-ingore-db
表示不需要记录二进制日志的数据库，如果有多个数据库可用逗号分隔，或者使用多binglog-ignore-db选项。
Replicate-do-db
表示需要同步的数据库，如果有多个数据可用逗号分隔，或者使用多个replicate-do-db选项。
Replicate-ignore-db
表示不需要同步的数据库，如果有多个数据库可用逗号分隔，或者使用多个replicate-ignore-db选项。
Master-connect-retry
master-connect-retry=n表示从服务器与主服务器的连接没有成功，则等待n秒（s）后再进行管理方式（默认设置是60s）。如果从服务器存在mater.info文件，它将忽略些选项。
Log-slave-updates
配置从库上的更新 *** 作是否写入二进制文件，如果这台从库，还要做其他从库的主库，那么就需要打这个参数，以便从库的从库能够进行日志同步。
Slave-skip-errors
在复制过程，由于各种原因导致binglo中的sql出错，默认情况下，从库会停止复制，要用户介入。可以设置slave-skip-errors来定义错误号，如果复制过程中遇到的错误是定义的错误号，便可以路过。如果从库是用来做备份，设置这个参数会存在数据不一致，不要使用。如果是分担主库的查询压力，可以考虑。
Sync_binlog=1 Or N
Sync_binlog的默认值是0，这种模式下，MySQL不会同步到磁盘中去。这样的话，Mysql依赖 *** 作系统来刷新二进制日志binary log，就像 *** 作系统刷新其他文件的机制一样。因此如果 *** 作系统或机器（不仅仅是Mysql服务器）崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，可以使用sync_binlog全局变量，使binlog在每N次binlog写入后与硬盘同步。当sync_binlog变量设置为1是最安全的，因为在crash崩溃的情况下，你的二进制日志binary log只有可能丢失最多一个语句或者一个事务。但是，这也是最慢的一种方式（除非磁盘有使用带蓄电池后备电源的缓存cache,使得同步到磁盘的 *** 作非常快）。
即使sync_binlog设置为1，出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，Mysql服务器处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次 *** 作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在binlog中。可以用-innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。（注释：在Mysql 5.1版本中不需要-innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的binlog(sync_binlog=1)和（默认情况为真）InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，Mysql服务器从binlog剪切回滚的InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步（不接收回滚的语句）。
Auto_increment_offset和Auto_increment_increment
Auto_increment_increment和auto_increment_offset用于主－主服务器（master-to-master）复制，并可以用来控制AUTO_INCREMENT列的 *** 作。两个变量均可以设置为全局或局部变量，并且假定每个值都可以为1到65,535之间的整数值。将其中一个变量设置为0会使该变量为1。
这两个变量影响AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值，auto_increment_offset确定AUTO_INCREMENT列值的起点。
如果auto_increment_offset的值大于auto_increment_increment的值，则auto_increment_offset的值被忽略。例如：表内已有一些数据，就会用现在已有的最大自增值做为初始值。
重置mysql主从同步（MySQL Reset Master-Slave Replication）在mysql主从同步的过程中，可能会因为各种原因出现主库与从库不同步的情况，网上虽然有一些解决办法，但是有时很难彻底解决，重置主从服务器也许不是最快的办法，但却是最安全有效的。
下面将自己重置主从同步的步骤总结一下，以备不时之需。
master与slave均使用：centos6.0+mysql 5.1.61 ，假设有db1,db2两个数据库需要热备。
文中shell与mysql均使用root账号，在真实环境中，请根据情况更换。
1.停止slave服务器的主从同步
为了防止主从数据不同步，需要先停止slave上的同步服务。
STOP SLAVE
2.对master服务器的数据库加锁
为了避免在备份的时候对数据库进行更新 *** 作，必须对数据库加锁。
FLUSH TABLES WITH READ LOCK
如果是web服务器也可以关闭apache或nginx服务，效果也是一样的。
Slave_IO_Running,一个负责与主机的io通信,一个负责自己的slave mysql进程.下面写一下,这两个要是有no了,怎么恢复.
如果是slave_io_running no了,那么就我个人看有三种情况,一个是网络有问题,连接不上,像有一次我用虚拟机搭建replication,使用了nat的网络结构,就是死都连不上,第二个是有可能my.cnf有问题,配置文件怎么写就不说了,网上太多了,最后一个是授权的问题,replication slave和file权限是必须的.如果不怕死就all咯.
一旦io为no了先看err日志,看看爆什么错,很可能是网络,也有可能是包太大收不了,这个时候主备上改max_allowed_packet这个参数.
如果是slave_sql_running no了,那么也有两种可能,一种是slave机器上这个表中出现了其他的写 *** 作,就是程序写了,这个是会有问题的,今天我想重现,但是有时候会有问题,有时候就没有问题,现在还不是太明了,后面再更新,还有一种占绝大多数可能的是slave进程重启,事务回滚造成的,这也是mysql的一种自我保护的措施,像关键时候只读一样.
这个时候想恢复的话,只要停掉slave,set GLOBAL SQL_SLAVE_SKIP_COUNTER=1再开一下slave就可以了,这个全局变量赋值为N的意思是：
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave thread is not running. Otherwise, it produces an error.
呵呵,讲的比我清楚.
MYSQL镜像服务器因错误停止的恢复
下午主服务器,由于一些原因,导致死机,重启后,发现从服务器的数据没有跟上.
配好MYSQL主从也才前几天的事,没多少经验,第一次碰上这问题,有点焦急.不过,自己试了下,还算解决了：）
从服务器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服务器：mysqlhxmaster.000007 | 84450528 |
已经过后很多了,确实没跟上.
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有问题了,Slave_SQL_Running应该是Yes才对.
再往下看,有错误的提示：
Last_Errno: 1053
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1START SLAVE. Query: 'INSERT INTO hx_stat_record .(一句SQL语句)'
这里有说明要怎么 *** 作了：）
先stop slave,然后执行了一下提示的语句,再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1START SLAVE
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了,从服务器也在几分钟内把堆积的log处理完了,两边又同步了：)
从MYSQL服务器Slave_IO_Running: No的解决2
早晨机房意外断电,导致了发现mysql从服务器同步异常.使用以前碰到的Slave_SQL_Running为No的解决办法无效,仍然无法同步.
查看一下状态show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服务器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql错误日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master '[email protected]:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228
这次是Slave_IO_Running为No,从日志上来看,服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误,这个位置不存在,于是无法同步.
查看一下这个Log的最后几行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
尝试从损坏之前的位置开始
SLAVE STOP
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220
SLAVE START
无效!
只好从新的日志开始
SLAVE STOP
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0
SLAVE START
此时Slave_IO_Running恢复为Yes,同步进行了!观察了会儿,没有任何出错迹象,问题解决.
另外,出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据. 您可能感兴趣的文章:
mysql主从同步复制错误解决一例
win2003 安装2个mysql实例做主从同步服务配置
Mysql主从同步备份策略分享
windows环境下mysql数据库的主从同步备份步骤(单向同步)
mysql主从同步快速设置方法
MySQL 数据库双向镜像、循环镜像(复制)
Mysql 主从数据库同步(centos篇)
解读mysql主从配置及其原理分析(Master-Slave)
mysql SKIP-NAME-RESOLVE 错误的使用时机造成用户权限
mysql 有关“InnoDB Error ib_logfile0 of different size”错误
MYSQL同步 Slave_IO_Running: No 或者Slave_SQL_Running: No的解决方法[已测]
Windows mysql 双向同步设置方法 详细篇
win2003 mysql单向同步配置步骤[已测]
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）