mysql读写分离引擎选择方案_Mysql读写分离方案－MySQL Proxy环境部署记录

Mysql的读写分离可以使用MySQL Proxy和Amoeba实现，其实也可以使用MySQL-MMM实现读写分离的自动切换。MySQL Proxy有一项强大功能是实现"读写分离"，基本原理是让主数据库处理写方面事务，让从库处理SELECT查询；Amoeba for MySQL是一款优秀的中间件软件，同样可以实现读写分离，负载均衡等功能。下面重点说下Mysql Proxy:

Mysql Proxy的原理图

顺便贴下Mysql Proxy的工作拓扑图

部署MySQL Proxy实现读写分离并提高并发负载的操作记录

0)机器环境

1)Mysql主从复制部署(在三台mysql节点机上部署，本案例是一主两从架构)

2)在proxy机器上安装mysql-proxy

3)读写分离测试

读写分离，延迟是个大问题，要确保主从同步这一环节不要有延迟。

---------------mysql主从同步延迟原理----------------

－> mysql主从同步原理

主库针对读写操作，顺序写 binlog，从库单线程去主库读"写操作的binlog",从库取到 binlog在本地原样执行(随机写),来保证主从数据逻辑上一致.

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卡住了，需求需求执行一段时间，那么所有之后的DDL会等待这个 DDL执行完才会继续执行，这就导致了延迟.由于master可以并发，Slave_sql_running线程却不可以，所以主库执行 DDL需求一段时间，在slave执行相同的DDL时，就产生了延迟.

-> 主从同步延迟产生原因

当主库的TPS并发较高时，产生的DDL数量超过Slave一个 sql线程所能承受的范围，那么延迟就产生了，当然还有就是可能与 slave的大型 query语句产生了锁等待

首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高

次要原因：读写 binlog带来的性能影响，网络传输延迟

->  mysql主从同步加速

1)sync_binlog在slave端设置为0

2)–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。

3)直接禁用slave端的binlog

4)slave端，如果使用的存储引擎是innodb，innodb_flush_log_at_trx_commit =2

再有就是进行分库分表处理，这样减少数据量的复制同步操作