什么是MySQL主从架构
首先，大家来看一张图
从上图中，可以看出，MySQL主从架构利用的是MySQL的主从复制原理,它主要分三个过程
1.master 主机将操作记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件，binary log events
- slave 将 master 的 binary log events 拷贝到它的中继日志（relay log）
- slave 重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL 复制是异步的且串行化的
简单的来说就是 slave 节点会从 master 读取 bin-log 来进行数据同步。
问题：从服务器永远会比主服务器慢一点？
回答:是的，因为在一个事务处理中,往数据库写的速度比较快，但是产生的二进制文件是先存在缓存空间中的，当事务结束之后，再一条一条的同步到二进制文件中，再一条一条发给从服务器，从服务器再一条条执行，所以会慢很多。
问题：从服务器需不需要二进制日志
回答:一般的主从复制是不需要的,从服务器只需要读取主服务器的日志就可以了。如果是有做主从切换或者多级复制的话，就需要用到从服务器的二进制日志了。
问题：有哪些使用场景？
回答:MySQL可用性备份,高可用，读写分离，异地容灾，分摊负载等
下面我们就开始简单地配置一下 MySQL 的主从复制架构。
MySQL配置文件: Windows下为my.ini，Linux下为my.cnf
- 把192.168.1.1作为主库服务器,把192.168.1.2作为从库服务器，在主库上给从库创建一个可以读取主库 bin-log 的账号
mysql> grant replication slave on *.* to 'slaveroot'@'192.168.1.2' identified by '123456';
mysql> flush privileges;
2.修改主库的配置信息,在配置文件中 [mysqld] 后面配置上下面的内容
# 编辑配置文件 添加相关配置
log-bin = /home/binlog/demo/master-binlog
# 选择一个唯一的server-id
serve-id = 1
#需要同步的数据库
binlog-do-db=demo
#忽略的库
binlog-ignore-db=mysql
binlog-ignore-db=test
- 修改配置文件后，重启服务
> service mysqld restart
如果启动失败，通过cat /var/log/mysqld.log | tail -30 查看 mysql 启动失败的日志，从日志内容寻找解决方案
- 查看主服务器当前二进制日志名和偏移量，这个操作的目的是为了在从数据库启动后，从这个点开始进行数据的恢复
mysql> show master status;
主库配置完成后，下面我们开始操作从库的配置
- 修改从库的配置文件
server-id=2
master-host=192.168.1.1
master-user=slaveroot
master-password=123456
master-port=3306
replicate-do-db=demo
配置完成后进行重启数据库。如果重启失败，报错。则直接在从库上执行下面的 SQL 语句来操作。
mysql> change master to master_host=‘192.168.1.1’,
master_user=‘slaveroot’,
master_password=‘123456’,
master_log_file=‘mysql-bin.000001’,
master_log_pos=‘1304’;
# 后面两个参数要和主库保持一致
mysql> show slave status;
mysql> slave start;
当结果中 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 都显示为 YES，则表明搭建成功。
注意：为了保证搭建成功，不受防火墙影响，大家可以把主从两台服务器上的防火墙都给关了。
复制过程中的相关线程
- master：dump线程
- slave：IO线程 和 sql线程
说明:
salve的I线程是连接到master的dump线程的，如果主服务器宕机的 那么IO线程就无法工作了，但是sql线程还是可以继续工作的，因其主要是监控中继日志的变化的，中继日志没变化，它也只是变为空闲而已。所以 当master重启之后，从服务器只需要重连IO线程 而sql线程不需要重启。
如果主服务在运行过程中宕机，日志还在缓存空间没有同步到二进制日志文件中怎么办？从服务器得不到事件。让主服务器事务已提交必须立即写到二进制日志中， 配置主服务器同步二进制文件 用于事务安全.
mysql> sync_binlog = on;
db快速回滚恢复,防止发生删库跑路
问:一旦发生删库或其他危险性操作, 比如update不带条件式的修改(你又没开update保护)，应该如何补救？
答:从库延迟一小时
#一小时间隔后重新连上主机把所有的数据全部同步过来,然后立马断开,这个从库会与主库保持1个小时的数据差距.从库的服务器上执行:
mysql> stop slave;
mysql> change master to master_delay = 1800; #1800s后才同步
mysql> start slave;
※说明:
这个方法有个缺点就是: 从库在连上主库进行同步的一小段时间内刚好发生了删库事故或其他update不带条件的灾难,这个时候根本无法恢复. 因此最好开设双从库的1小时延迟同步: 即对第一台从库执行一次延时1小时的命令change master to master_delay=3600;
过过半小时后再对另一台从机执行change master to master_delay=3600;
那么现在这两台从机就有半小时的同步间隔时间,即使事故发生在第一台从机连接的时候,仍旧有半小时的补救时间
总结
好了，以上及时MySQL简单的主从架构搭建，以后可以继续分享工作中用到的场景。