kf_panda

MySQL5.5 除了支持内置的异步复制机制，还提供了接口支持半同步复制的机制。异步复制的缺点：MySQL复制默认是异步复制，Master将事件写入binlog，但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下，如果Master宕机，事务在Master上已提交，但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制，此时Slave

我们都知道binlog_format有三种可选配置：STATEMENT、ROW、MIXED，相应地，基于这三种模式的Replication分别称为SBR(STATEMENT BASED Replication)、RBR、MBR。 同时，我们也知道，MySQL Replication可以支持比较灵活的binlog规则，可以设置某些库、某些表记录或者忽略不记录。通常地，我们强烈建议不要设置这些

1.Replication 线程　 　Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程-binlo

1、出现错误提示、 Slave I/O: error connecting to master 'backup@192.168.1.x:3306' - retry-time: 60  retries: 86400, Error_code: 1045解决方法从服务器上删除掉所有的二进制日志文件，包括一个数据目录下的master.

在MySQL5.6发布之后添加GTID、多线程等新特性之后,回顾一下从MySQL5.5引入的半同步复制.半同步的原理主要是:数据库执行更改前，确认更改操作至少被写入一台Slave的中继日志.半同步主要是保证数据完整性防止数据丢失.实验环境MySQL5.6.16主:mysql> grant replication client,replication slave on *.* t

GTID简介什么是GTIDGTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。 GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。下面是一个GTID的具体形式3E11FA47-71CA-11E1-9E33-C80AA942

MySQL的主从复制有多种原因可以导致延迟（网络、硬件、SQL复杂程序等综合因素），这个是公认的了，下面谈谈怎样监测复制的延迟，以及怎样尽量的解决延迟的问题。    延迟的监测Seconds_behind_master在SLAVE上执行SHOW SLAVE STATUS，监控Seconds_behind_master列值，备库Seconds_Behind_Master值是通过将服务器当前的时间

对于Seconds_Behind_Master，很多人误以为是从库落后主库多少秒，从Seconds_Behind_Master单词的字面上看也是如此。但是看看Seconds_Behind_Master的原理就明白了，其延迟是通过备库当前的时间戳减去SQL线程正在执行的SQL语句的时间戳计算出来的。可以进行下面两个测试：测试一：把备库当前时间进行调整。测试二：断开备库的网络连