产品动态
产品公告
自动读写分离介绍
本文主要介绍 TDSQL-C MySQL 版数据库代理服务的自动读写分离、功能优势、读写分离路由规则。
自动读写分离
自动读写分离
目前，大量现网用户的业务场景中存在读多写少、业务负载无法预测等情况，在有大量读请求的应用场景下，单个实例可能无法承受读取压力，甚至会对业务产生影响。为了实现读取能力的弹性扩展，分担数据库压力，可以创建一个或多个只读实例，利用只读实例满足大量的数据库读取需求。但此类解决方案需要业务侧支持读写分离改造，其代码的健壮性决定了业务读写分离的质量，对用户的技术要求较高，而且灵活性和可扩展性较差。
故创建只读实例后，可以通过开通数据库代理，配置访问地址策略，然后在应用程序中配置数据库代理地址，使写请求自动转发到主实例，读请求自动转发到各个只读实例。数据库代理除了具备自动读写分离功能，也能为其他业务痛点提供更好的解决方案，具体如下：
负载无法预测或波动不规律/负载“洪峰”现象明显的场景
在互联网业务场景中，业务负载和访问压力往往是不可预估、不平稳的，会出现频繁的波动和“洪峰”。如果业务侧大量使用短连接访问数据库，那么在这些场景中很容易产生大量的新建连接，即数据库与应用程序间的连接数，容易随着业务访问压力的频繁变动而波动。
数据库代理的连接管理，使用户可以通过有效重用数据库连接，来适当扩展处理不可预测工作负载的应用程序连接问题。首先，使多个应用程序连接可以共享数据库连接，以有效利用数据库资源；其次，允许用户通过调节打开的数据库连接数，来保持数据库性能；最后，可删除无法使用的应用程序请求，以保留应用程序的整体性能和可用性。
应用程序与数据库频繁建立和断开连接的场景
基于无服务器、PHP 或 Ruby on Rails 等技术构建的应用程序，可能会频繁打开和关闭数据库连接来满足应用程序请求。
数据库代理可以帮助用户维护数据库连接池，以避免对数据库计算和用于建立新连接的内存造成不必要的压力。
数据库访问连接长时间处于空闲状态并未释放的场景
SaaS 或电子商务行业中的传统应用程序，可能会使数据库连接保持空闲状态，以最大程度减少用户重新参与的响应时间。用户可以使用数据库代理来保留空闲连接，仅根据需要建立数据库连接，而不是为支持大多数空闲连接过度调大阈值或升级为更高配的数据库。
提高数据库 PaaS 服务故障转移场景下的平滑和稳定
使用数据库代理，用户可以构建可透明容忍数据库故障转移（主动/被动）的应用程序，而无需编写复杂的故障处理代码。数据库代理自动将读流量路由到新的数据库实例，同时保留应用程序连接。
功能优势
自助读写分离，统一访问地址。
原生链路支持，提升性能，减少维护成本。
可设权重和阈值，可供用户灵活选择。
具备故障转移能力，即使数据库代理故障请求也能正常访问主库。
读写实例发生切换、变配、只读实例增减等情况，数据库代理可动态热加载配置，不会出现网络中断或重启。
功能说明
TDSQL-C MySQL 版数据库代理服务具备自动读写分离能力，并支持为读写实例和多个只读实例做读权重的分配，需注意，此处的权重是面向读请求（非事务）权重的分配策略。
读写分离路由规则
发送到主实例
CREATE、ALTER、DROP、RENAME 等 DDL 语句。
INSERT、UPDATE、DELETE 等 DML 语句。
SELECT FOR UPDATE 语句。
临时表相关语句。
部分系统函数调用（如 last_insert_id()）以及所有自定义函数调用。
LOCK 相关语句。
开启事务后的语句（包括 set autocommit=0）。
存储过程。
用“;”连接的多语句。
KILL（SQL 语句中的 KILL，非命令 KILL）。
所有对用户变量的查询和更改。
发送到只读实例
事务外的读（SELECT）语句。
注意：
只读分析引擎不支持读写分离。
发送到所有实例
show processlist 语句。
所有系统变量的更改（SET 命令）。
USE 命令。
文档反馈