江苏专业做网站的公司有哪些,微网站建设对微网站进行策划,东莞关键词优化推广,查不到网站备案MySQL 主备的基本原理MySQL 主备切换流程.png主备同步流程图备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程#xff0c;专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的#xff1a;在备库 B 上通过 change master 命令#xff0c;设置…MySQL 主备的基本原理MySQL 主备切换流程.png主备同步流程图备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的在备库 B 上通过 change master 命令设置主库 A 的 IP、端口、用户名、密码以及要从哪个位置开始请求 binlog这个位置包含文件名和日志偏移量。在备库 B 上执行 start slave 命令这时候备库会启动两个线程就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。主库 A 校验完用户名、密码后开始按照备库 B 传过来的位置从本地读取 binlog发给 B。备库 B 拿到 binlog 后写到本地文件称为中转日志(relay log)。sql_thread 读取中转日志解析出日志里的命令并执行。binlog 三种格式1. Row日志中会记录成每一行数据被修改的形式然后在 slave 端再对相同的数据进行修改。优点在 row 模式下bin-log 中可以不记录执行的 SQL 语句的上下文相关的信息仅仅只需要记录那一条记录被修改了修改成什么样了。所以 row 的日志内容会非常清楚的记录下每一行数据修改的细节非常容易理解。而且不会出现某些特定情况下的存储过程或 function 以及 trigger 的调用和触发无法被正确复制的问题。缺点在 row 模式下所有的执行的语句当记录到日志中的时候都将以每行记录的修改来记录这样可能会产生大量的日志内容比如有这样一条 update 语句UPDATE product SET owner_member_id b WHERE owner_member_id a执行之后日志中记录的不是这条 update 语句所对应的事件 (MySQL 以事件的形式来记录 bin-log 日志) 而是这条语句所更新的每一条记录的变化情况这样就记录成很多条记录被更新的很多个事件。自然bin-log 日志的量就会很大。尤其是当执行 alter table 之类的语句的时候产生的日志量是惊人的。因为 MySQL 对于 alter table 之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。2. Statement每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master 端执行过的相同的 SQL 再次执行。优点在 statement 模式下首先就是解决了 row 模式的缺点不需要记录每一行数据的变化减少了 bin-log 日志量节省 I/O 以及存储资源提高性能。因为他只需要记录在 master 上所执行的语句的细节以及执行语句时候的上下文的信息。缺点在 statement 模式下由于他是记录的执行语句所以为了让这些语句在 slave 端也能正确执行那么他还必须记录每条语句在执行的时候的一些相关信息也就是上下文信息以保证所有语句在 slave 端杯执行的时候能够得到和在 master 端执行时候相同的结果。另外就是由于 MySQL 现在发展比较快很多的新功能不断的加入使 MySQL 的复制遇到了不小的挑战自然复制的时候涉及到越复杂的内容bug 也就越容易出现。在 statement 中目前已经发现的就有不少情况会造成 MySQL 的复制出现问题主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现比如sleep() 函数在有些版本中就不能被正确复制在存储过程中使用了 last_insert_id() 函数可能会使 slave 和 master 上得到不一致的 id 等等。由于 row 是基于每一行来记录的变化所以不会出现类似的问题。3. Mixed从 5.1.8 版本开始MySQL 提供了除 Statement 和 Row 之外的第三种复制模式Mixed实际上就是前两种模式的结合。在 Mixed 模式下MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化并不是所有的修改都会以 row 模式来记录比如遇到表结构变更的时候就会以 statement 模式来记录如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句那么还是会记录所有行的变更。循环复制问题通过上面对 MySQL 中 binlog 基本内容的理解你现在可以知道binlog 的特性确保了在备库执行相同的 binlog可以得到与主库相同的状态。因此我们可以认为正常情况下主备的数据是一致的。也就是说图 1 中 A、B 两个节点的内容是一致的。其实图 1 中我画的是 M-S 结构但实际生产上使用比较多的是双 M 结构也就是图 9 所示的主备切换流程。MySQL 主备切换流程 -- 双 M 结构.png对比图 9 和图 1你可以发现双 M 结构和 M-S 结构其实区别只是多了一条线即节点 A 和 B 之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。但是双 M 结构还有一个问题需要解决。业务逻辑在节点 A 上更新了一条语句然后再把生成的 binlog 发给节点 B节点 B 执行完这条更新语句后也会生成 binlog。(我建议你把参数 log_slave_updates 设置为 on表示备库执行 relay log 后生成 binlog)。那么如果节点 A 同时是节点 B 的备库相当于又把节点 B 新生成的 binlog 拿过来执行了一次然后节点 A 和 B 间会不断地循环执行这个更新语句也就是循环复制了。这个要怎么解决呢从上面的图 6中可以看到MySQL 在 binlog 中记录了这个命令第一次执行时所在实例的 server id。因此我们可以用下面的逻辑来解决两个节点间的循环复制的问题规定两个库的 server id 必须不同如果相同则它们之间不能设定为主备关系一个备库接到 binlog 并在重放的过程中生成与原 binlog 的 server id 相同的新的 binlog每个库在收到从自己的主库发过来的日志后先判断 server id如果跟自己的相同表示这个日志是自己生成的就直接丢弃这个日志。