数据库的主从复制/读写分离

数据库主从复制原理：

主服务器的增删改成sql会记录到a-bin.log文件中，从服务器拿到这个文件，执行文件中相应的sql语句

读写分离必须基于主从复制才能实现：

mycat作用：接管多个数据库，对数据库进行心跳检测，当主服务器故障后，自动实现主从切换

主从复制

主从复制的原理 : 简而言之，MySQL-A在进行写操作时，都会更新数据库A的二进制sql日志,通过网络传输将二进制sql日志传递给数据库B，B再将二进制sql日志写入B数据库，完成主从复制。

 影响MySQL-A数据库的操作，在数据库执行后，都会写入本地的日志系统A中。

 假设，实时的将变化了的日志系统中的数据库事件操作，在MYSQL-A的3306端口，通过网络发给MYSQL-B。

 MYSQL-B收到后，写入本地日志系统B，然后一条条的将数据库事件在数据库中完成。

 那么，MYSQL-A的变化，MYSQL-B也会变化，这样就是所谓的MYSQL的复制，即MYSQL replication。

 在上面的模型中，MYSQL-A就是主服务器，即master，MYSQL-B就是从服务器，即slave。

 日志系统A，其实它是MYSQL的日志类型中的二进制日志，也就是专门用来保存修改数据库表的所有动作，即bin log。【注意     MYSQL会在执行语句之后，释放锁之前，写入二进制日志，确保事务安全】

 日志系统B，并不是二进制日志，由于它是从MYSQL-A的二进制日志复制过来的，并不是自己的数据库变化产生的，有点接力的感觉，称为中继日志，即relay log。

 可以发现，通过上面的机制，可以保证MYSQL-A和MYSQL-B的数据库数据一致，但是时间上肯定有延迟，即MYSQL-B的数据是滞后的。

【即便不考虑什么网络的因素，MYSQL-A的数据库操作是可以并发的执行的，但是MYSQL-B只能从relay log中读一条，执行下。因此MYSQL-A的写操作很频繁，MYSQL-B很可能跟不上。】

主从复制解决的问题

数据如何不被丢失，备份，读写分离，数据库负载均衡，高可用

关于Mysql主从复制的配置，主从复制是Mysql自带的功能，跟MyCat没有关系！！！

读写分离

在数据库集群架构中，让主库负责处理事务性查询，而从库只负责处理select查询，让两者分工明确达到提高数据库整体读写性能。当然，主数据库另外一个功能就是负责将事务性查询导致的数据变更同步到从库中，也就是写操作

读写分离的好处

分摊服务器压力，提高机器的系统处理效率

增加冗余，提高服务可用性，当一台数据库服务器宕机后可以调整另外一台从库以最快速度恢复服务

使用Mycat实现读写分离

Mycat是一个开源的分布式数据库系统，但是因为数据库一般都有自己的数据库引擎，而Mycat并没有属于自己的独有数据库引擎，所有严格意义上说并不能算是一个完整的数据库系统，只能说是一个在应用和数据库之间起桥梁作用的中间件。
在Mycat中间件出现之前，MySQL主从复制集群，如果要实现读写分离，一般是在程序段实现，这样就带来了一个问题，即数据段和程序的耦合度太高，如果数据库的地址发生了改变，那么我的程序也要进行相应的修改，如果数据库不小心挂掉了，则同时也意味着程序的不可用，而对于很多应用来说，并不能接受；

  引入Mycat中间件能很好地对程序和数据库进行解耦，这样，程序只需关注数据库中间件的地址，而无需知晓底层数据库是如何提供服务的，大量的通用数据聚合、事务、数据源切换等工作都由中间件来处理；
  Mycat中间件的原理是对数据进行分片处理，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成完成的数据库存储，有点类似磁盘阵列中的RAID0