0、导读
主从复制环境中，IO、SQL线程都很正常，也没设置过滤规则，但数据就是无法复制到slave上，什么原因？
1、问题描述
事实上，这个案例发生已经有一阵子了，一直拖到现在我才整理。
发现一个主从环境中，slave上的io_thread、sql_thread状态均正常，relay log也正常接收来自master的event，但slave上却无法正常应用这些event，个别表数据没有复制过来。而且slave上的binlog也没有记录这些表上的操作。
2、原因分析
接到现场后，第一反应是是先检查是否设置了ignore/do规则，发现并不是这个原因引起的。
…
[获取更多]0、导读
在MySQL 5.7下采用多源复制方式，从5.6复制数据过来，会有问题吗？
1、问题描述
Q群里有位朋友想尝鲜5.7的多源复制，于是用MySQL 5.7版本作为slave，把MySQL 5.6作为master，想要将数据进行汇总，发现此路不通。
他在my.cnf中设置了2个选项，开启并发复制：
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 4
启动复制线程后，结果在错误日志中不断有类似下面的信息：
Transaction is tagged with inconsistent logical timestamps: sequence_number (823267087) <= last_committed (1301275374434324336)
执行 SHOW SLAVE STATUS\G 查看状态：
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
…
Last_Errno: 1756
Last_Error: … The slave …
[获取更多]0、导读
在复制环境中，有个表的列类型总是被修改，导致复制进程报错停止
1、问题描述
问题发生在朋友的数据库上，做了主从复制，其中某表有一列类型是INT，但是该表上的INSERT事件在BINLOG中却总被记录为MEDIUMINT类型，导致这个事件在SLAVE上执行失败。
相关现场信息见下：
MySQL版本：官方5.5.版本。
表DDL定义：
CREATE TABLE `t` (
`userid` int(10) unsigned NOT NULL DEFAULT 0,
这个表上的INSERT事件在BINLOG中的记录：
### INSERT INTO `imysql`.`t`
### SET
### @1=207 /* MEDIUMINT meta=0 nullable=0 is_null=0 */
我们看到BINLOG中，这个列类型显示为MEDIUMINT，这个事件在SLAVE上就会报告下面的错误，导致SLAVE无法继续复制：
…
[获取更多]导读
遇到SLAVE延迟很大，binlog apply position一直不动的情况如何排查？
问题描述
收到SLAVE延迟时间一直很大的报警，于是检查一下SLAVE状态（无关状态我给隐去了）：
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.000605
Read_Master_Log_Pos: 1194
Relay_Log_File: mysql-relay-bin.003224
Relay_Log_Pos: 295105
Relay_Master_Log_File: mysql-bin.000604
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error:
Exec_Master_Log_Pos: 294959
Relay_Log_Space: 4139172581
Seconds_Behind_Master: 10905
可以看到，延迟确实很大，而且从多次show slave status的结果来看，发现binlog的position一直不动。
Read_Master_Log_Pos: 1194
Relay_Log_File: mysql-relay-bin.003224 …导读
MySQL主从复制环境中，如何才能保证主从数据的一致性呢？
关于主从复制
现在常用的MySQL高可用方案，十有八九是基于 MySQL的主从复制（replication）来设计的，包括常规的一主一从、双主模式，或者半同步复制（semi-sync replication）。
我们常常把MySQL replication说成是MySQL同步（sync），但事实上这个过程是异步（async）的。大概过程是这样的：
步骤1和步骤3之间是异步进行的，无需等待确认各自的状态，所以说MySQL replication是异步的。
MySQL semi-sync replication在之前的基础上做了加强完善，整个流程变成了下面这样：
本次专题是 MySQL高可用方案选型，这个专题想必有很多同学感兴趣。
高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了，直接进入主题。
可选MySQL高可用方案
MySQL的各种高可用方案，大多是基于以下几种基础来部署的：
在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方案。其余几种方案在生产上用的并不多，我们只简单说下。
基于主从复制的高可用方案 双节点主从 + keepalived/heartbeat
…
[获取更多]导读
在MySQL复制中，如何忽略slave节点上发生的主键冲突、数据不存在等错误。
在MySQL复制中，如果slave节点上遇到错误，比如数据不存在或者主键冲突等错误时，想要忽略这些错误，可以采用以下几种方法：
1、未启用GTID模式时
只需通过设定 SQL_SLAVE_SKIP_COUNTER 的值，即可忽略一些复制事件。例如：
#需要先关闭SLAVE服务
root@imysql.com [test]> STOP SLAVE;
#忽略N个事件（event），通常一个SQL是一个事件
root@imysql.com [test]> SET SQL_SLAVE_SKIP_COUNTER=N;
#再次启动SLAVE服务
root@imysql.com [test]> START SLAVE;
2、启用GTID模式时
启用GTID，想要忽略某些错误事件就稍微麻烦一点点了。
首先，我们需要先查看当前SLAVE复制的进度：
mysql> SHOW SLAVE STATUS\G …
[获取更多]本文是基于MySQL-5.7.7-rc版本，未来可能 还会发生更多变化。
1、SQL MODE变化
a. 默认启用 STRICT_TRANS_TABLES 模式；
b. 对 ONLY_FULL_GROUP_BY 模式实现了更复杂的特性支持，并且也被默认启用；
c. 其他被默认启用的sql mode还有 NO_ENGINE_SUBSTITUTION；
【iMySQL建议】
对广大MySQL使用者而言，以往不是那么严格的模式还是很方便的，在5.7版本下可能会觉得略为不适，慢慢习惯吧。比如向一个20字符长度的VARCHAR列写入30个字符，在以前会自动截断并给个提示告警，而在5.7版本下，则直接抛出错误了。个人认为这倒是一个好的做法，避免各种奇葩的写法。
【新特性实践】
-- 查看默认的 sql_mode [yejr@imysql.com]> select @@sql_mode; +-----------------------------------------------------------------------------------+ | @@sql_mode | …[获取更多]
一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式（以InnoDB引擎为主）完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。
ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master，需要想办法进行优化。
…
[获取更多]我们都知道binlog_format有三种可选配置：STATEMENT、ROW、MIXED，相应地，基于这三种模式的Replication分别称为SBR(STATEMENT BASED Replication)、RBR、MBR。 同时，我们也知道，MySQL Replication可以支持比较灵活的binlog规则，可以设置某些库、某些表记录或者忽略不记录。
通常地，我们强烈建议不要设置这些规则，默认都记录就好，在Slave上也是如此，默认所有库都进行Replicate，不要设置DO、IGNORE、REWRITE规则。 如果非要设置这些规则的话，可能会导致某些场景下或者某些特定的SQL无法被记录，就需要特别注意了。
我经过比较简单的测试，不同的binlog_format可能会导致某些SQL不被记录的情况总结如下：
[获取更多]
