发生背景：
mysql主从数据库是单数据库使用到一定程度后，数据的存放很多大，触及到瓶颈；数据的查询过慢，qps过高，导致查询反应慢；可能遇到的故障，数据库异常停止，数据丢失。
解决：
从量上解决，就是业务的划分卫多个数据库，也就是微服务化，最常见的一个系统分为多个自服务系统。比如分为订单系统，商品系统，用户系统。吧一个系统中的表分开了多个数据库中。一个书库的量就降低下来。这个是从横向的划分。
纵向的划分，就是把分库分表。比如给一个用户系统分3个mysql服务。轮询的进行数据操作。这样一个数据库的数据就少了。其次是把表划分为比如用户的 分为亚洲用户，非洲用户，欧美用户。解决了访问高还有数据库异常的问题。
最后还有我们常说的读写分离。写的操作和读的操作分开，写的锁，不影响读，提高性能。一般系统查询的非常多，不会应为查询的过多，花费时间长，致使mysq性能开销不足。
技术实现上；
mysql中通过bin.log，以及relay.log的复制，把主的数据写入到从数据库。
mysql的事务在进行提交之气那，会先把操作的sql,以二进制的形式转化到bin.log中。
主数据库卫Master，从库卫slave。从库订阅主库的bin.log信息。一旦有新的bin.log信息，就拉去过来然后通过IO写入到relay.log。然后relay.log再通过线程解析，写入到从库的bin.log中。
简单说从库盯着主库，主库有信息，从库就copy，然后写入到从库。
从库写入中涉及的知识点：
实际生成工作中，会因为服务器异常或者是数据满，处理不过来等情况，导致数据复制没成功到从库。这个时候的解决需要了解那些没写入到从库。就需要查看bin.log日志。
简单说下这个排查结果就是，1.找到这个bin.log。 去分析日志系统，2根绝postion，或者是时间去过去这段时间的操作sql. 3,执行到从库中
其中mysql5.0 和8.0都自带bin.log的二进制的解析工具。mysqlbinlog的操作日志。
最基本的语法 mysqlbinlog 日志文件：
举例子：
第一步的找到bin.log位置。
第二部的展现里里面的事件，一个event就是一个事务操作。其中重点解释pos，就是点的意思。
end_log_pos.结束的点。可以理解成row的ID。
shwo binlog events in "指定的log文件"\G
最后就是截取那些范围的sql 。这个网上比较多，
基本语法 mysqlbinlog 开始时间范围 结束时间点 那个binlog文件
例：mysqlbinlog --stop-datetime="2017-08-16 15:00:00" mysqld-bin.000001 偷懒复制的
mysqlbinlog -o 10000 mysqld-bin.000001 这是根绝pos进行的筛选 。 具体玩法对照文档，当正则，或者sql范围选择基本就OK
mysql中bin.log的三种记录方式：
1.row级别的 2.sql级别的 3.混合的mixed
Mysql的主从复制的机制：
这个就是怎么进行主从复制的。基本三种方式
1.mysql3.0多的 异步。就是master写了bin.log后不管从库是否接收到，直接接着执行事务。会导致从库的数据准确性没法保证。从而数据库从库查询数据可能异常，不准确。
2.半同步 就是master形成bin.log后，传递给从库，从库拿到后返回给主客一个信息。任意一个从库反馈就行。这样回到之主库等待从库，从而影响主库的时间和效率，从而导致系统性能差。但一定时间后也会直接忽略从库的执行。所以也不太准确
3.组复制。说白了就是一组服务只要写的事务，都会互相通知，一旦形成事务冲突，以先有的事务位置，另一个回退。这个保证了事物的高可用。
3.1组复制 分为单从，多主从。单主从，就是只有一个master，进行写操作，如果异常就提起一个slave为master.多主的话，就是所有的都是master .
