摘要：
####实验环境 三台服务器 10.154.0.111 主 node 10.154.0.112 从1 node 10.154.0.113 从2 manager ####搭建MySQL MHA 1、下载MHA软件 这里使用郭老师提供的MHA-2019-6.28.zip软件包，点我下载 0.58版本下载 阅读全文
摘要：
####GTID复制介绍 全称 Global Transaction ID GTID会对每个已提交的事务提供一个唯一的编号，用于区分不同事务，可用于备份恢复，DUMP并发传输，SQL线程并发回放等。 5.6版本默认没有开启。 5.7版本默认没有开启也有类似于GTID的功能。 官方定义如下 GTID 阅读全文
摘要：
上文提到过半同步复制，看《mysql入门与提高实践》发现有这个的介绍，所以学习一下。 ####主从复制模式介绍 异步复制：主库将binlog的更新发给从库后，并不关心从库是否写入relaylog中。故可能会造成数据不一致问题。默认使用该模式。 全同步复制：主库将等待所有更新从库都写入relaylog 阅读全文
摘要：
####过滤复制介绍 主库只想同步一部分数据库或只同步除某些数据库以外的库到从库中去。 ####主库方面配置 需要用到的参数 mysql> show slave status \G binlog_do_db：#相当于白名单，只同步哪些库 binlog_ignore_db：#相当于黑名单，不同步哪些库 阅读全文
摘要：
####延时从库介绍 如果主从及时同步，那么主库误删除操作drop database xxx会立刻同步到从库上，这样会造成数据的损失，所以我们需要人为制造延时。 我们可以在主库做了某项操作后，决定从库延时多长时间回放sql。 ####配置过程 在从库输入如下命令，延时5分钟用于测试 mysql>st 阅读全文
摘要：
####什么是主从延时 主库发生了数据的变化，从库很长时间才同步过来。 查看主从复制延时时间，单位秒 mysql> show slave status \G; Seconds_Behind_Master: 0 注意：当该参数等于0时，也只能认为传输过程中没有延迟， 此时还要根据对比主库的Positi 阅读全文
摘要：
####故障说明 故障主要出现在从库的两个线程即IO线程跟SQL线程 在从库执行如下命令检查报错原因 mysql> show slave status \G; Slave_IO_Running: Yes Slave_SQL_Running: Yes #以下为具体报错信息，用于排错 Last_IO_E 阅读全文
摘要：
####主从复制监控 以下命令在主库运行 #查看向从库发送binlog的状态，repl为复制账号，线程为Binlog Dump mysql> show processlist; + + + + + + + + + | Id | User | Host | db | Command | Time | 阅读全文
摘要：
####涉及的文件 主库需要使用到binlog文件 从库需要使用xxx-relay-bin.00000N、master.info、relay-log.info文件 下面讲解从库涉及到的3个文件 1、master.info 连接主库相关信息，已经接收到的binlog位置点信息，默认存放在文件中 存储位 阅读全文
摘要：
###一、主从复制介绍 全称MySQL Replication 1、主从复制基于binlog来实现的 2、主库发生新的操作,都会记录binlog 3、从库取得主库的binlog进行恢复 4、主从复制的过程是异步 ###二、主从复制的前提条件 1、主从数据库时间要一致，网络通畅未被防火墙拦截 2、2个 阅读全文