MySQL-Proxy有人在稳定和性能如何？有人在生产环境用过吗？

Question

这个东东据说稳定性和性能欠佳，生产环境中有人大规模使用过吗？

Answer 1

目前业务上大概是这样考虑设计的 ，蓝色没有在后期应该会加上去用实现读写分离

Answer 2

啊米巴试试吧

Answer 3

mysql的话 读写分离 可以试试用amoeba

阿里的那个开源的corba就免了，属于半开源！

Answer 4

一个东西永远不要把它用极致了，不然问题多得你抗都抗不住，想死的心都有。

Answer 5

我在产生环境中使用过，但并不理想，原因有以下几点：

1.　需要增加额外的运维监控，增加了工作量

2.　增加了可能的故障点，得考虑mysql_proxy的可靠性问题

3.　不支持一些特殊的处理：如强制主库读取(对数据一致性有要求时，为避免主从几步延迟导致业务数据错乱)；业务需要，运行时只读取指定的从库

mysql_proxy并不能解决这个问题，而且在程序中使用多数据库连接，造成更多问题．后来解决办法是：

程序中开发一个数据库访问层，支持以下特性：

 * 1. 支持一主多从模式
 * 2. 自动读写分离（读请求自动转发到从库 写请求自动分发到主库）
 * 3. 从库负载均衡
 * 4. 强制主库读（对数据一致性要求较高场合使用较多）
 * 5. 强制指定读取从库节点(默认情况下随机选择从库)
 * 6. 查询缓存（仅对select,show查询有效）
 * 7. 从库故障转移 当从库产生故障时 自动选取其它从库 未实现
 * 8. 如果没有配置从库，所有的读写请求均分发到主库

这样，在运行时根据业务需要设置数据库连接属性即可

Answer 6

我在产生环境中使用过，但并不理想，原因有以下几点：

1.　需要增加额外的运维监控，增加了工作量

2.　增加了可能的故障点，得考虑mysql_proxy的可靠性问题

3.　不支持一些特殊的处理：如强制主库读取(对数据一致性有要求时，为避免主从几步延迟导致业务数据错乱)；业务需要，运行时只读取指定的从库

mysql_proxy并不能解决这个问题，而且在程序中使用多数据库连接，造成更多问题．后来解决办法是：

程序中开发一个数据库访问层，支持以下特性：

 * 1. 支持一主多从模式
 * 2. 自动读写分离（读请求自动转发到从库 写请求自动分发到主库）
 * 3. 从库负载均衡
 * 4. 强制主库读（对数据一致性要求较高场合使用较多）
 * 5. 强制指定读取从库节点(默认情况下随机选择从库)
 * 6. 查询缓存（仅对select,show查询有效）
 * 7. 从库故障转移 当从库产生故障时 自动选取其它从库 未实现
 * 8. 如果没有配置从库，所有的读写请求均分发到主库

这样，在运行时根据业务需要设置数据库连接属性即可

Answer 7

是的，在前端把压力挡住，数据库很闲：）

Answer 8

没试过：）

Answer 9

没试过：）