mysql主从复制
一、什么是主从复制读写分离
1、概念
mysql的主从复制，从字面上理解就是有两个数据库分饰两个角色，主数据库、从数据库，复制可以简单理解为从库数据是复制主库的数据。实际上主数据库可能有多个，从数据库也可能有多个。读写分离即主库负责写入，从库承担查询的任务，这个实现需要在应用层配置。
2、实际生产环境的mysql部署分类
单点模式
单点模式是最简单的模式，只有一台数据库服务器，部署最简单。但是存在单点风险，一旦这台服务器挂了，整个系统也就挂掉了。
主备模式
主备模式应该是各个线上服务系统的最低配置了，比如你在各云平台购买的数据库服务一般都会开启备份功能。一旦主节点出现问题，还可以切换到备份节点，不至于整个系统瘫痪。
主备又分为一主一备、一主多备。多个备份是为了保证更高的安全性，万一主节点出现问题的时候，碰巧备份节点也出问题呢。
当主节点出现问题的时候要切换到备份节点，切换方式又分为手动切换和自动切换。手动切换具有一定的延时，当主节点出现问题时，只能等运维人员发现或者收到系统通知。
主从模式
主从配置一般都是和读写分离相结合，主服务器负责写数据，从服务器负责读数据，并保证主服务器的数据及时同步到从服务器。
主从模式又分为一主一从、一主多从和多主多从，越往后部署越复杂，同时，系统稳定性更高。主从模式可以更好的分担数据库压力，将插入更新操作和查询操作分开，提高系统整体性能。
二、主从复制的作用
1、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
3、读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
三、主从复制的原理
主节点
1、当主节点上进行 insert、update、delete 操作时，会按照时间先后顺序写入到 binlog 中；
2、当从节点连接到主节点时，主节点会创建一个叫做 binlog dump 的线程；
3、一个主节点有多少个从节点，就会创建多少个 binlog dump 线程；
4、当主节点的 binlog 发生变化的时候，也就是进行了更改操作，binlog dump 线程就会通知从节点 (Push模式)，并将相应的 binlog 内容发送给从节点；
从节点
当开启主从同步的时候，从节点会创建两个线程用来完成数据同步的工作。
I/O线程：此线程连接到主节点，主节点上的 binlog dump 线程会将 binlog 的内容发送给此线程。此线程接收到 binlog 内容后，再将内容写入到本地的 relay log。
SQL线程：该线程读取 I/O 线程写入的 relay log，并且根据 relay log 的内容对从数据库做对应的操作。
主从配置一般都是和读写分离相结合，主服务器负责写数据，从服务器负责读数据，并保证主服务器的数据及时同步到从服务器。
四、三步轻松构建主从
1、master主服务器配置（103.251.237.42）
编辑my.cnf （命令查找文件位置：find / -name my.cnf）
在[mysqld]中注释掉 bind-address = 127.0.0.1 不然mysql无法远程
server-id = 1 中 1 是可以自己定义的，但是需要保持它的唯一性，是服务器的唯一标识
1.log_bin 启动MySQL二进制日志
2.binlog_do_db 指定记录二进制日志的数据库
3.binlog_ignore_db 指定不记录二进制日志的数据库。
2、登陆主服务器mysql 创建从服务器用到的账户和权限;
@之后IP可访问主服务器，这里值定从服务器IP
新建密码为masterbackup的masterbackup 用户，并赋予replication slave 权限
可以看到用户masterbackup 已经添加
3、查看主数据库的状态
记录 mysql-bin.000007 以及 276，编写以下命令待用；
change master to master_host='103.251.237.42',master_port=3306,master_user='masterbackup',master_password='masterbackup',master_log_file='mysql-bin.000007',master_log_pos=276;
2、Slave从服务器配置上的配置（103.251.237.45）
1.编辑my.cnf（命令查找文件位置：find / -name my.cnf）
在[mysqld]中
relay-log = slave-relay-bin
relay-log-index = slave-relay-bin.index
暂时不清楚这是做什么的。加入这两条。
重启mysql服务
登陆mysql，停止同步命令
执行用上面准备的命令； 登录Slave从服务器，连接Master主服务器：
重新启动数据同步；
查看Slave信息；如图两句都为yes，则状态正常
3、从主从服务器测试结果
在主服务器创建一个数据库，在从服务器上查看刚才创建的数据库。
五、必问面试题
1、主从的好处是？
2、主从的原理是？
3、从数据的读的延迟问题了解吗？如何解决？
谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作，主库对所有DDL和 DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高，下一步， 问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺 序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要 执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什 么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
4、做了主从后服务器挂了怎么办
从服务器挂了：
在主服务的 binlog dump 线程将指定的 binlog 信息发给从服务时，除了日志内容，还包括本次发送内容在主服务端的 bin-log 日志文件名称以及位置信息。
从服务的 I/O 线程接收到信息后将日志内容写入realy-log 文件(mysql-relay-bin.xxxxxx)的末端，并将读取到的主服务端的 bin-log 的文件名和位置记录到 master-info 中（通过 show slave status 中的 Master_Info_File 字段可以看到 master.info 保存的位置），以便下一次读取时能告诉主服务从哪里开始同步。
从服务的 SQL 线程检测到 realy-log 新增了内容后，解析日志文件生成对应的 sql 语句，并应用这些 sql 到数据库，保证主从数据一致性。
所以，及时从库挂掉了，因为有 master.info 记录了上一次同步的位置，只要同步服务再次启动，那就可以从上次同步的位置继续增量同步了。
主服务器挂了：
那话说主库宕了怎么办，这就是另一个悲伤的故事了，就没有从库挂掉这么简单了，如果马上启动那就是最好的解决办法。如果由于硬件或者比较棘手的问题导致没办法立即重启，那就要选一个从库升级为主库，选择的标准是数据最接近主库的，也就是最后一次同步时间最晚的。如果有可能（比如主服务只是数据库无法启动，但机器还在）还要到主服务上拉取最新的 bin-log 进行同步。最后进行一系列设置将选中的从库变更为主库配置。
本文内容参考借鉴以下链接：
https://www.jianshu.com/p/803e3dc409d4
https://www.cnblogs.com/fengzheng/p/13401783.html
https://developer.aliyun.com/article/42638
