MySQL Router 8.2读写分离功能详解：配置、测试与实战应用

对于很多开发者来说，数据库的读写分离是一个提升应用性能和扩展性的重要手段。以往，这通常需要在应用层进行逻辑判断，或者借助第三方中间件来实现。好消息是，随着 MySQL Router 8.2 的发布，官方终于内置了对读写分离的原生支持，让整个部署和管理过程变得更加简单透明。

简单来说，MySQL Router 现在可以自动识别 SQL 请求是读操作还是写操作，并将它们智能地路由到合适的数据库实例——写操作发给主库（Source），读操作分发给从库（Replica）。这一切对应用程序几乎是透明的，无需修改任何业务代码。

为了清晰地展示这一功能，我们将通过一个最简单的架构：MySQL InnoDB ReplicaSet 来进行演示。

MySQL InnoDB ReplicaSet 基础架构

一个典型的 InnoDB ReplicaSet 包含一个主实例（Source）和一个或多个通过异步复制连接的从实例（Replica），其结构如下：

我们可以通过 MySQL Shell 查看这个复制集的状态。输出结果清晰地显示了主实例（127.0.0.1:3310，角色为 PRIMARY，模式 R/W）和从实例（127.0.0.1:3320，角色为 SECONDARY，模式 R/O）的信息。

配置并启动 MySQL Router 8.2

接下来，我们来配置 MySQL Router 以启用读写分离。执行引导配置后，Router 会生成详细的连接信息。

从上图可以看到，Router 为我们的 ReplicaSet myreplica 开放了多个端口。我们需要特别关注的是 Read/Write Split Connections: localhost:6450，这正是实现智能读写分离的关键端口。

配置完成后，我们也可以在 MySQL Shell 中通过 ReplicaSet 对象查看到已注册的 Router 信息及其监听的端口，其中明确包含了读写分离端口 rwSplitPort: 6450。

测试读写分离效果

现在，让我们使用读写分离端口 6450 连接到 MySQL，并进行一系列测试，观察 Router 是如何工作的。

首先，我们建立一个连接并执行一个简单的 SELECT 查询（读操作）：

可以看到，第一个 SELECT 语句被路由到了从实例（端口 3320）。接着，我们开启一个事务（暗示后续可能有写操作）：

start transaction;

执行后，再次查询 @port，发现连接已经被 Router 自动切换到了主实例（端口 3310）。这说明 Router 能够根据会话上下文（是否开启事务）智能判断，将开启了事务的连接指向主实例，以确保读写一致性。

我们还可以通过显式声明“只读事务”来进一步控制路由行为。当使用 start transaction read only; 开启一个只读事务后，后续的查询即便在事务中，也会被固定路由到从实例。

原理与手动控制

这一切是如何实现的呢？奥秘在于 MySQL Router 的配置文件。在生成的配置中，我们可以找到读写分离相关的路由段：

[routing:bootstrap_rw_split]
bind_address=0.0.0.0
bind_port=6450
destinations=metadata-cache://myreplica/?role=PRIMARY_AND_SECONDARY
routing_strategy=round-robin
protocol=classic
connection_sharing=1
client_ssl_mode=PREFERRED
server_ssl_mode=PREFERRED
access_mode=auto

关键参数是 access_mode=auto，它使得 Router 能够自动进行读写分离。此外，你还可以在会话中通过 SQL 命令手动指定路由模式，例如强制将当前会话的所有请求指向主库或只读从库：

通过执行 ROUTER SET access_mode='read_write'; 或 ROUTER SET access_mode='read_only';，我们可以即时切换当前连接的路由目标，这在某些调试或特定业务场景下非常有用。

总结

MySQL Router 8.2 原生支持的读写分离功能，为 MySQL 的高可用和扩展性部署提供了极大的便利。它通过自动识别事务和语句类型，将读写流量分别导向主实例和只读实例，从而优化数据库集群的性能和资源利用率。

这项功能的优势在于：

1. 对应用透明：应用程序无需修改代码，只需连接 Router 的读写分离端口即可。
2. 智能路由：基于事务和语句自动判断，保证数据一致性。
3. 灵活控制：支持会话级手动覆盖路由策略。
4. 简化运维：作为官方组件，与 MySQL 生态集成度更高，管理更简单。

对于正在构建或升级 高可用架构 的团队来说，这无疑是一个值得尝试和集成的重要特性。如果你在实践过程中有任何心得体会，欢迎在云栈社区与其他开发者交流讨论。