用 pt-table-checksum 时，会不会影响业务性能？
实验
实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。
我们先建一对主从：
然后用 mysqlslap跑一个持续的压力：
开另外一个会话，将 master 上的 general log 打开：
然后通过 pt-table-checksum 进行一次比较：
查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：
将该线程的 *** 作单独列出来：
*** 作比较多，我们一点一点来说明：
这里工具调小了 innodb 锁等待时间。使得之后的 *** 作，只要在 innodb 上稍微有锁等待，就会马上放弃 *** 作，对业务影响很小。
另外工具调小了 wait_timeout 时间，倒是没有特别的作用。
工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。
RR 级别是数据对比的基本要求。
工具通过一系列 *** 作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。
接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。
之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。
以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。
工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。
总结
本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。
还是那个观点，性能测试不能相信道听途说，得通过实验去分析。
MySQL在互联网应用中已经遍地开花，但是在银行系统中，还在生根发芽的阶段。本文记录的是根据某生产系统实际需求，对数据库高可用方案从需求、各高可用技术特点对比、实施、测试等过程进行整理，完善Mysql高可用方案，同时为后续开展分布式数据库相关测试做相应准备。
存储复制技术： 传统IOE架构下，常用高可用方案，靠存储底层复制技术实现数据的一致性，优点数据安全性有保障，限制在于是依赖存储硬件，实施成本较高。
keepalived+双主复制： 两台MySQL互为主从关系，即双主模式，通过Keepalived配置虚拟IP，实现当其中的一台数据库故障时，自动切换VIP到另外一台MySQL数据库，备机快速接管业务来保证数据库的高可用。
MHA： MHA部署在每台mysql服务器上，定时探测集群中的master节点，当master出现故障时，它可以自动将最新的slave提升为新的master，然后将所有其他的slave重新指向新的master，优点在最大程度保证数据的一致性的前提下实现快速切换，最少需要3台服务器，存在数据丢失的可能性。
PXC： Percona eXtra Cluster是Percona基于galera cluster封装的集群方案。不同于普通多主复制，PXC保障强一致性和实时同步，故障切换更快。但是也需要3个节点，配置相对复杂，对性能也稍有影响。
除了上述方案外，还有MMM、Heartbeat+DRBD等高可用方案，此处不做详细介绍。
综合评估下，本次实施采用了 keepalived+mysql双主实现数据库同城双机房的高可用。MySQL版本为： 5.7.21。 *** 作系统：Red Hat Enterprise Linux Server 7.3。
配置过程如下：
Mysql-master1: IP地址1 --以下简称master1
Mysql-master2: IP地址2 --以下简称master2
Mysql-vip : VIP地址 --应用连接使用
Mysql复制相关概念描述：
1、 Mysql主从复制图示：
2、 Mysql主从复制过程描述：
（1）master记录二进制日志：在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务写入二进制日志。在事务写入二进制日志完成后，master通知存储引擎提交事务。
（2）slave将master的binarylog拷贝到自己的中继日志：首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事务，如果已经同步了master，它会睡眠并等待master产生新的事件。I/O线程将这些事务写入中继日志。
（3）SQL slave thread处理该过程的最后一步：SQL线程从中继日志读取事务，并重放其中的事务而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步至备端。
为了便于后续数据库服务器的扩展，且在整个复制环境中能够自动地切换，降低运维成本，引入了当前主流的基于Mysql GTID的复制特性，工作原理及优缺点简介如下。
3、 GTID工作原理简介：
（1） master更新数据时，会在事务前产生GTID，一同记录到Binlog日志中。
（2） slave的I/O线程将变更的binlog写入到本地的relay log中。
（3） slave的sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
（4） 如果有记录说明该GTID的事务已经执行，slave会忽略。
（5） 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
（6） 在解析的过程中会判断是否有主键，如果有就用索引，如果没有就用全部扫描。
4、 GTID优点：
（1） 一个事务对应一个唯一的ID，一个GTID在一个服务器上 只会执行一次。（2） GTID是用来替代传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。
（3） 减少手工干预和降低服务故障时间，当主机宕机之后会通过软件从众多的备机中提升一台备机为新的master。
5、 GTID也存在一些限制：
（1） 不支持非事务引擎。
（2） 不支持create table … select 语句复制(主库直接报错)。
（3） 不允许一个sql同时更新一个事务引擎表和非事务引擎表。
（4） 在一个复制组中，必须要求统一开启GTID或者是统一关闭GTID。
（5） 开启GTID需要重启(5.7版本除外)。
（6） 开启GTID后，就不再使用原理的传统复制方式。
（7） 不支持create temporary table 和 drop temporary table语句。
（8） 不支持sql_slave_skip_counter。
前置条件：
主备两个节点使用行内统一的安装部署脚本安装mysql5.7.21介质(略)
Master1端创建应用的数据库(略)
1、 修改MySQL配置文件
参考相关配置规范，分别设置master1、master2的my.cnf文件，
其中server-id参数设置为不同值
由于后续keepalived会挂起VIP，应用通过VIP连接数据库，为了避免应用程序无法通过VIP访问，需将两个节点的bind-address参数注释掉；
2、 设置master1端自动半同步模式
Mysql的同步模式主要有如下3种：
a. 主从同步复制：数据完整性好，但是性能消耗略高；
b. 主从异步复制：性能消耗低，但容易出现不一致；
c. 主从半自动复制：介于上述两种之间，既保持了数据的完整性，又提高了性能；
基于上述特性，建议采用半自动同步模式，由于后续要配置为双主模式，因此任一节点其角色既为master又为slave，因此相关的master/slave插件要同时配置，过程如下。
（1） 首先查看库是否支持动态加载(默认都支持)
（2） 主从库上分别安装插件
作为主库，安装插件semisync_master.so
作为从库，安装插件semisync_slave.so
（3） 安装完成后，从plugin表中能够看到刚刚安装的插件
（4） 分别打开主从库半同步复制
同时添加到各自的my.cnf中，在后续数据库实例重启时自动加载该配置。
此时查看状态还没有启动
（5） 两个节点分别启动IO进程
（6） 查看半同步状态
3、 将master1设为master2的主服务器
（1）在master1主机上创建授权账户，允许在master2主机上连接
（2）将主库master1数据导出
（3）将master.sql传输到master2上并导入
（4）在master2端将master1设置为自己的主库，并开启slave功能
在master2上查看slave状态
至此master1到master2的主从复制关系已经建立完成。
4、 将master2设为master1的主服务器
在master1上执行
在master1上查看slave状态
1、keepalived相关概念说明：
keepalived是集群管理中保证集群高可用的一个软件解决方案，其功能类似于heartbeat，用来防止单点故障
keepalived是以VRRP协议为实现基础的，VRRP全称VirtualRouter Redundancy Protocol，即虚拟路由冗余协议。
虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip，master会发组播（组播地址为224.0.0.18），当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，这样的话就可以保证路由器的高可用了。
keepalived主要有三个模块，分别是core 、check和vrrp。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责 健康 检查，包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。同时为了避免出现脑裂，应关闭防火墙或者开启防火墙但允许接收VRRP协议。
2、keepalived的安装配置
（1）配置本地yum源，在master1和master2两台服务器上安装keepalived的相关依赖包Kernel-devel/openssl-devel/popt-devl等
配置指向rhel-7.5.iso的yum本地源，步骤略
注意：如不知道keepalived需要哪些依赖包，可到下载后的源码解压目录下查看INSTALL 文件内容，安装需要的依赖包，源码安装任何一个软件都要养成查看源码包文档的习惯，比如INSTALL，README,doc等文档，可以获得很多有用的信息。
（2）在两台mysql上解压缩并编译安装keepalived
（3）master1、master2上分别配置keepalived.conf
注意上图红色字体中两个节点配置相同处及差异。
说明：keepalived只有一个配置文件keepalived.conf，里面主要包括以下几个配置区域：
· global_defs：主要是配置故障发生时的通知对象以及机器标识。
· vrrp_instance：用来定义对外提供服务的VIP区域及其相关属性。
· virtual_server：虚拟服务器定义
（4）同时两个节点上都需要添加检测脚本
作用：是当mysql停止工作时自动关闭本机的keeplived服务，从而实现将故障主机踢出热备组，因每台机器上keepalived只添加了本机为realserver，所以当mysqld正常启动后，我们还需要手动启动keepalived服务。
（5）分别启动两个节点的keepalived服务
检查两个节点keepalived启动进程
检查两个节点的vip挂载情况
（6）主备机故障切换测试
停止master2的mysql服务，看keepalived 健康 检查程序是否会触发脚本，自动进行故障切换，步骤略
查看master1节点的VIP挂载情况，验证是否实现了自动切换，步骤略
说明在master2服务器的mysql服务发生故障时，触发了脚本，自动完成了切换。
（7）现在我们把master2的mysql服务开起来，并且keepalived的服务也需要启动。
即便master2的mysql服务和keepalived服务都重新开启了，master1仍然是主master了，master2未对主master的权利进行抢夺，说明设置的nopreempt参数生效了，为了保证群集的稳定性，生产环境不允许抢占配置，只有当master1的mysql服务坏掉的时候，master2才会再次成为主master，否则它永远只能当master1的备份。（注：nopreempt一般是在优先级高的mysql上设置）
Sysbench是一个模块化的、跨平台、多线程基准测试工具，可用于评估数据库负载情况，通过sysbench命令配置IP地址、端口号、用户名、密码连接到指定的数据库db1中，创建多个表，并快速插入指定条数的记录，观察主备库同步效率
(1) 下载开源工具sysbench-0.4.12.14.tar.gz，放置在相应目录下并解压
(2) 使用iso配置本地yum源并安装Sysbench如下的依赖包(步骤略)：autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc
(3) 编译sysbench
编辑配置文件/etc/ld.so.conf中添加mysql lib目录/mysql/app/5.7.21/lib，并执行命令ldconfig生效
(4) 执行sysbench压测
使用sysbench工具向主节点的db1数据库中创建5张表，并且每张表分别插入10万条记录
同时观察备机同步效率
几个重要的参数说明：
B、半自动同步模式、异步模式切换测试
(1) 检查主备同步状态，及同步参数设置
rpl_semi_sync_master_enabled参数表示启用半同步模式；
rpl_semi_sync_master_timeout参数单位为毫秒，表示主库事务等待从库返回commit成功信息超过10秒就降为异步模式，不再等待从库，等探测到从库io线程恢复后，再返回为半自动同步；
rpl_semi_sync_master_wait_no_slave参数表示事务提交后需要等待从库返回确认信息；
(2) 将slave的io线程停止
(3) 使用sysbench向master写入少量的数据，本例创建一张表，并插入10条记录，命令包装在1.sh测试脚本中
通过记录的时间戳发现，master在等待了slave10秒无响应，自动切换为异步模式，将数据写入本地。
(4) Slave启动io线程，数据自动追平
至此MySQL主主复制配置完成，运行在半自动同步模式，通过keepalived实现Mysql的HA高可用。
上线后应符合统一的标准监控策略，添加备份协议对数据进行周期备份并保存到带库中，以及定期的数据恢复测试。
由于是靠keepalived实现的高可用，还应将如下资源添加到监控管理平台：
1、 对每台数据库主机的3个keepalived进程进行监控；
2、 对主备节点的io线程、sql线程工作状态进行监控；
mysql双机热备实现原理分析，在本文经过深思熟虑和多次用不同的方式实测试后。最后在这篇文章中，用一个小例子来完成mysql双机热备的实现。
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的值被忽略。例如：表内已有一些数据，就会用现在已有的最大自增值做为初始值。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）