浅谈MySQL Replication(复制)基本原理

核心提示： 首先，一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，浅谈MySQL Replication(复制)基本原理(2)，性能受到了一定的限制，异步复制的延迟也会比较长，而且不会出现某些特定情况下的存储过程，或function，另外，Slave端从Master端

首先，一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，性能受到了一定的限制，异步复制的延迟也会比较长。

另外，Slave端从Master端获取bin-log过来之后，需要接着解析日志内容，然后在自身执行。在这个过程中，Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误，那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave端的压力比较大的时候，这个过程的时间可能会比较长。

所以，后面版本的MySQL为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用MySQL的cluster来解决了。不过MySQL的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。

2、MySQL Replication复制实现级别

MySQL Replication复制可以是基于一条语句（Statement level），也可以是基于一条记录（Row level），可以在MySQL的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。

Row Level：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。

优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。