mysql主从复制

前言一、主从复制目的二、主从复制过程三、主从复制注意事项四、主从复制权衡问题五、主从复制问题总结

写博客是自己对知识梳理，目前是写给自己看，算是自己学习后的作业，也是为了养成一个良好的习惯。

1. 数据备份，保证mysql数据的可靠性；
2. 提高mysql的吞吐量，可以实现读写分离，主库负责写，从库负责读。

主从复制过程：
	1. master端 主库所有的DDL和DML操作都会顺序写到binlog中；
	2. master端 会有log dump线程异步将binlog文件推送给slave；
	3. slave端 I/O线程会定期请求master的binlog文件，并将binlog写入到relay log中；
	4. slave端 SQL线程会读取并解析relay log并在slave中重放sql。
	
具体过程如下图所示：

1. master要开启binlog功能，并且要赋予slave远程连接权限；
2. 至少需要2台mysql服务器，且服务器上mysql版本必须一致；
3. 要保证master服务器和slave服务器的时间同步。

在考虑mysql主从复制时，以下这些都是要好好权衡：
	1. 成本问题 包括设备成本和运维成本；
	2. 架构复杂度问题 项目整体架构复杂度提升，架构师是否能hold住；
	3. 主从数据写入强一致性问题；
	4. 主从同步的延迟问题；

1.从库是否越多越好？
	在一主多从架构下可以实现读写分离，则mysql的读性能会极大提升，但并不是从库越多就越好，还有考虑master和slave的网络开销问题，
多个slave时master会新建多个dump线程来推送binlog给slave这也会拖垮master性能。

2. 主从延迟问题分析:
	2.1. master的binlog是顺序写效率高，而salve在重放sql时随机io；
	2.2.salve的sql线程是单线程处理sql重放，当master并发较高时超过了salve线程处理的速度；
	2.3.salve在处理大型query或慢查询时产生的等待锁；
	2.4.master和salve网络io问题导致延迟（可控）。
	
3. 主从延迟的解决方案：
	3.1. 采用分库架构，不同业务对应不同的mysql来分散压力；
	3.2. 一主多从、读写分离架构，让从库帮忙分担主库的压力（从库建议不要超过5个）；
	3.3. master和salve部署在同一个局域网中；
	3.4. 使用redis缓存分担数据库压力；
	3.5. 将全文检索或有复杂查询数据存放到es中，分担DB压力；
	3.6. 杜绝mysql中的慢sql；
	3.7. 大表的数据做分表分库优化。

1. 主从复制目的是做数据备份和读写分离，提高mysql的吞吐量和数据的可靠性；
2. 主从复制过程：master 由dump线程将binlog异步推送给slave；slave 由I/O线程读取binlog并写入到relaylog，再由SQL线程重放relaylog的sql；
3. 主从复制架构在选择前先考虑下成本等问题，杜绝过度设计；
4. 主从复制延迟主要问题就是从库查询性能和主库高并发写问题。