网站免费源码,qq空间钓鱼网站制作,wordpress媒体库制作文件夹,wordpress 倡萌 相册全面了解 8.1.0 版本新功能#xff1a;InnoDB Cluster 只读副本的相关操作。 作者#xff1a;Miguel Arajo 高级软件工程师 / Kenny Gryp MySQL 产品总监 本文来源#xff1a;Oracle MySQL 官网博客 * 爱可生开源社区出品。
前言
MySQL 的第一个 Innovation 版本 8.1.0 已…全面了解 8.1.0 版本新功能InnoDB Cluster 只读副本的相关操作。 作者Miguel Araújo 高级软件工程师 / Kenny Gryp MySQL 产品总监 本文来源Oracle MySQL 官网博客 * 爱可生开源社区出品。
前言
MySQL 的第一个 Innovation 版本 8.1.0 已经发布我们将推出 MySQL InnoDB Cluster 只读副本。
在 MySQL InnoDB Cluster 中副本Secondray节点的主要目的是在主Primary节点发生故障时做好切换替代高可用性。这是由 MySQL 组复制MGR插件配合完成的。副本节点的另一个用途是减少主节点的只读工作负载。
现在可以向数据库拓扑结构中添加异步副本节点这些副本节点可以用于
将读流量从主节点或者其他副本节点转移过来分担它们的读压力。设置专门用于读取的副本节点。设置专门用于报表等特定目的的副本节点。通过添加多个读取副本节点实现超出其他副本节点处理能力范围的扩容。 MySQL InnoDB Cluster 会管理这些副本节点的操作包括
MySQL Router 会自动重新导向流量。MySQL Shell 负责配置、初次预配使用 InnoDB Clone 插件。复制配置和任何想要进行的拓扑结构变更。
只读副本节点也可以与 MySQL InnoDB ClusterSet 配合使用这个模式下副本节点可以添加到主集群或副本集群中。
MySQL Router 会识别这些读取副本节点并根据一些配置选项将读流量重新导向到它们。这些读取副本节点会从主节点或者其他副本节点进行复制如果复制中断或成员变更例如新主节点选举它会自动重新连接到另一个成员。
创建只读副本
将读取副本节点添加到集群中和添加从节点很相似。Admin API 的外观和交互方式保持不变这可以确保最佳的用户体验。
假设您已经有一个运行中的集群可以使用新增的这个命令来添加读取副本节点
Cluster.addReplicaInstance(instance[, options])
mysqlsh-js cluster.addReplicaInstance(rome4:3306)Setting up rome4:3306 as a Read Replica of Cluster rome.
Validating instance configuration at rome4:3306...
This instance reports its own address as rome4:3306
Instance configuration is suitable.
* Checking transaction state of the instance...省略……* Waiting for clone to finish...
NOTE: rome4:3306 is being cloned from rome1:3306
** Stage DROP DATA: Completed
** Clone Transfer FILE COPY ############################################################ 100% CompletedPAGE COPY ############################################################ 100% CompletedREDO COPY ############################################################ 100% CompletedNOTE: rome4:3306 is shutting down...* Waiting for server restart... ready
* rome4:3306 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 4.30 GB transferred in 4 sec (1.08 GB/s)
* Configuring Read-Replica managed replication channel...
** Changing replication source of rome4:3306 to rome1:3306
* Waiting for Read-Replica rome4:3306 to synchronize with Cluster...
** Transactions replicated ############################################################ 100% rome4:3306 successfully added as a Read-Replica of Cluster rome.
如此简单一个新的副本就添加到集群中了。和普通的集群成员一样只读副本也支持 Clone 或者增量预配。
和往常一样可以用 Cluster.status() 命令检查集群的状态
mysqlsh-js cluster.status()
{clusterName: rome, defaultReplicaSet: {name: default, primary: rome1:3306, ssl: REQUIRED, status: OK, statusText: Cluster is ONLINE and can tolerate up to ONE failure., topology: {rome1:3306: {address: rome1:3306, memberRole: PRIMARY, mode: R/W, readReplicas: {rome4:3306: {address: rome4:3306, role: READ_REPLICA, status: ONLINE, version: 8.1.0}}, replicationLag: applier_queue_applied, role: HA, status: ONLINE, version: 8.1.0}, rome2:3306: {address: rome2:3306, memberRole: SECONDARY, mode: R/O, readReplicas: {}, replicationLag: applier_queue_applied, role: HA, status: ONLINE, version: 8.1.0}, rome3:3306: {address: rome3:3306, memberRole: SECONDARY, mode: R/O, readReplicas: {}, replicationLag: applier_queue_applied, role: HA, status: ONLINE, version: 8.1.0}}, topologyMode: Single-Primary}, groupInformationSourceMember: rome1:3306
}
你可能注意到新增的只读副本运行在 rome4:3306 端口它被放置在集群主节点 rome1:3306 下面这表示它会将 rome1:3306 当作源节点进行数据同步即它会从 rome1:3306 节点复制数据。
从主节点复制数据有一些优点如可以减少潜在的复制延迟。但是它也可能增加主节点的负载。为了提供灵活性以及根据不同场景选择我们改进让这个配置成为可配置项。
运行原理源节点识别
如上所示只读副本默认会从主节点进行同步如果主从切换或故障转移发生它会自动重新连接到集群新的主节点。换句话说它总是会跟踪主节点保持与集群的同步。
这是通过 MySQL 复制技术里的异步复制连接故障转移特性实现的。副本会检查组复制状态存储一份潜在源服务列表。如果当前源服务下线它会从列表中选择一个新的源。
这个源列表可以手动或自动维护后者支持集群复制拓扑。在这种情况下故障转移机制可以监控成员变更相应添加或删除候选源。此外它也能区分主从节点。这与 MySQL InnoDB Cluster 中副本集复制主集群的方式一致。
有了这样灵活的架构Admin API 可以根据每个用户的需求管理和配置读取副本。
运行原理配置只读副本
选择故障恢复候选项
从主节点复制有降低延迟的优点但也可能增加主节点压力。
我们了解自动故障转移机制工作原理理解不同配置选项
优先从主节点复制优先从副本节点中选择一个复制设置候选列表
可以在添加副本时定义或随时改变现有副本的配置。下图显示Rome 地区副本选择从节点作为源Brussels 副本选择主节点作为源。 作为一个例子让我们使用指定实例作为源同时预定义故障恢复候选列表来向集群添加一个新的副本
mysqlsh-js cluster.addReplicaInstance(rome5:3306, {replicationSources: [rome2:3306, rome3:3306]})
Setting up rome5:3306 as a Read Replica of Cluster rome.Validating instance configuration at rome5:3306...This instance reports its own address as rome5:3306Instance configuration is suitable.
* Checking transaction state of the instance...
NOTE: A GTID set check of the MySQL instance at rome5:3306 determined that it is missing transactions that were purged from all cluster members.
NOTE: The target instance rome5:3306 has not been pre-provisioned (GTID set is empty). The Shell is unable to determine whether the instance has pre-existing data that would be overwritten with clone based recovery.
The safest and most convenient way to provision a new instance is through automatic clone provisioning, which will completely overwrite the state of rome5:3306 with a physical snapshot from an existing cluster member. To use this method by default, set the recoveryMethod option to clone.Please select a recovery method [C]lone/[A]bort (default Clone): c
* Waiting for the donor to synchronize with PRIMARY...
** Transactions replicated ############################################################ 100% Monitoring Clone based state recovery of the new member. Press ^C to abort the operation.
Clone based state recovery is now in progress.NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.* Waiting for clone to finish...
NOTE: rome5:3306 is being cloned from rome2:3306
** Stage DROP DATA: Completed
** Clone Transfer FILE COPY ############################################################ 100% CompletedPAGE COPY ############################################################ 100% CompletedREDO COPY ############################################################ 100% CompletedNOTE: rome5:3306 is shutting down...* Waiting for server restart... ready
* rome5:3306 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 4.30 GB transferred in 6 sec (717.27 MB/s)* Configuring Read-Replica managed replication channel...
** Changing replication source of rome5:3306 to rome2:3306* Waiting for Read-Replica rome5:3306 to synchronize with Cluster...
** Transactions replicated ############################################################ 100% rome5:3306 successfully added as a Read-Replica of Cluster rome.
此次就是完成向集群添加运行在 rome5:3306 上的新的读取副本。
这个副本使用一个固定的候选失败列表包含 rome2:3306 和 rome3:3306其中 rome2:3306 是当前运行中的源服务。列表中的其他成员是潜在的失败转移候选他们的顺序决定权重靠前的权重高靠后的权重低。
让我们查看集群描述以更直观地了解当前的拓扑结构
mysqlsh-js cluster.describe()
{clusterName: rome, defaultReplicaSet: {name: default, topology: [{address: rome1:3306, label: rome1:3306, role: HA}, {address: rome2:3306, label: rome2:3306, role: HA}, {address: rome3:3306, label: rome3:3306, role: HA}, {address: rome4:3306, label: rome4:3306, replicationSources: [PRIMARY], role: READ_REPLICA}, {address: rome5:3306, label: rome5:3306, replicationSources: [rome2:3306, rome3:3306], role: READ_REPLICA}], topologyMode: Single-Primary}
}
同样使用扩展状态我们可以查看当前拓扑结构的更多信息
mysqlsh-js cluster.status({extended:1})
{clusterName: rome, defaultReplicaSet: {GRProtocolVersion: 8.0.27, communicationStack: MYSQL, groupName: 33cfdab9-3469-11ee-9f3b-d08e7912e4ee, groupViewChangeUuid: 33cfe2b0-3469-11ee-9f3b-d08e7912e4ee, groupViewId: 16913336945761559:7, name: default, paxosSingleLeader: OFF, primary: rome1:3306, ssl: REQUIRED, status: OK, statusText: Cluster is ONLINE and can tolerate up to ONE failure., topology: {rome1:3306: {address: rome1:3306, applierWorkerThreads: 4, fenceSysVars: [], memberId: e304af5d-3466-11ee-8d97-d08e7912e4ee, memberRole: PRIMARY, memberState: ONLINE, mode: R/W, readReplicas: {rome4:3306: {address: rome4:3306, applierStatus: APPLIED_ALL, applierThreadState: Waiting for an event from Coordinator, applierWorkerThreads: 4, receiverStatus: ON, receiverThreadState: Waiting for source to send event, replicationLag: null, replicationSources: [PRIMARY], replicationSsl: TLS_AES_256_GCM_SHA384 TLSv1.3, role: READ_REPLICA, status: ONLINE, version: 8.1.0}}, replicationLag: applier_queue_applied, role: HA, status: ONLINE, version: 8.1.0}, rome2:3306: {address: rome2:3306, applierWorkerThreads: 4, fenceSysVars: [read_only, super_read_only], memberId: e6eb91c6-3466-11ee-aca6-d08e7912e4ee, memberRole: SECONDARY, memberState: ONLINE, mode: R/O, readReplicas: {rome5:3306: {address: rome5:3306, applierStatus: APPLIED_ALL, applierThreadState: Waiting for an event from Coordinator, applierWorkerThreads: 4, receiverStatus: ON, receiverThreadState: Waiting for source to send event, replicationLag: null, replicationSources: [rome2:3306, rome3:3306], role: READ_REPLICA, status: ONLINE, version: 8.1.0}}, replicationLag: applier_queue_applied, role: HA, status: ONLINE, version: 8.1.0}, rome3:3306: {address: rome3:3306, applierWorkerThreads: 4, fenceSysVars: [read_only, super_read_only], memberId: ea08833f-3466-11ee-b87c-d08e7912e4ee, memberRole: SECONDARY, memberState: ONLINE, mode: R/O, readReplicas: {}, replicationLag: applier_queue_applied, role: HA, status: ONLINE, version: 8.1.0}}, topologyMode: Single-Primary}, groupInformationSourceMember: rome1:3306, metadataVersion: 2.2.0
}
改变故障候选项
改变源配置就像改变实例选项一样简单。Cluster.setInstanceOption() 增强了一个新的选项 replicationSources允许执行这个操作
让我们修改第一个读取副本的配置优先从第二实例而不是主实例进行同步。
mysqlsh-js cluster.setInstanceOption(rome4:3306, replicationSources, secondary)
Setting the value of replicationSources to secondary in the instance: rome4:3306 ...WARNING: To update the replication channel with the changes the Read-Replica must be reconfigured using Cluster.rejoinInstance().
Successfully set the value of replicationSources to secondary in the cluster member: rome4:3306.
为让新的设置立即生效我们需要使用 Admin API 非常有名的命令 Cluster.rejoinInstance() 强制实例重新加入集群
mysqlsh-js cluster.rejoinInstance(rome4:3306)
Rejoining Read-Replica rome4:3306 to Cluster rome...* Checking transaction state of the instance...
The safest and most convenient way to provision a new instance is through automatic clone provisioning, which will completely overwrite the state of rome4:3306 with a physical snapshot from an existing cluster member. To use this method by default, set the recoveryMethod option to clone.The incremental state recovery may be safely used if you are sure all updates ever executed in the cluster were done with GTIDs enabled, there are no purged transactions and the new instance contains the same GTID set as the cluster or a subset of it. To use this method by default, set the recoveryMethod option to incremental.Incremental state recovery was selected because it seems to be safely usable.NOTE: User mysql_innodb_replica_2506922964% already existed at instance rome1:3306. It will be deleted and created again with a new password.
** Changing replication source of rome4:3306 to rome2:3306* Waiting for Read-Replica rome4:3306 to synchronize with Cluster...
** Transactions replicated ############################################################ 100% strongRead-Replica rome4:3306 successfully rejoined to the Cluster rome.
说明和普通实例一样使用 Cluster.removeInstance() 可以从集群中删除读取副本。
路由读请求到副本
MySQL Router 在 InnoDB Cluster 中扮演着至关重要的角色所以现在它完全知晓只读副本的存在。Router 位于应用和集群之间将客户端流量定向到正确的目标。它可以为只读请求使用只读副本。但是从节点也可以那么它如何选择?
配置 Router 目标池
默认情况下Router 的行为不变即读流量定向到集群的从节点。但是现在是可配置的。
read_only_targets 模式接受以下可能的行为
secondaries只将目标集群的副本成员用作只读流量默认read_replicas只将目标集群的读取副本用于只读流量all将目标集群的所有读取副本以及其他副本成员一起用于只读流量
该模式可以通过另一个常见的命令 .setRoutingOption() 进行配置该命令可以在 Router、Cluster 或 ClusterSet 级别进行配置。
例如
mysqlsh-js cluster.setRoutingOption(read_only_targets, all)
Routing option read_only_targets successfully updated.
mysqlsh-js cluster.routingOptions()
{clusterName: rome, global: {read_only_targets: all, stats_updates_frequency: null, tags: {}}, routers: {domus::: {}}
}
下图显示了更复杂的拓扑其中 ClusterSet 由主集群Rome和部署了多个路由器的副本集群Brussels组成。 主要集群是包含 3 个主要成员和 3 个只读副本的 3 个成员集群。读取副本使用 sourcesList:secondary 因此它们从集群的次要成员进行复制。
部署在该数据中心的两个路由器使用主要集群作为目标集群并且被配置为使用所有读取目标即 read_only_targets:all 。
另一个数据中心的副本集群也是一个 3 个成员的集群包含 3 个只读副本它们被配置为从主集群主成员进行复制。两个路由器有不同的配置第一个路由器被配置为使用主要集群作为目标集群并且只将读取副本用于只读目标即 read_only_targets: read_replicas。另一个路由器被配置为使用 Brussels 作为目标集群并且只将次要成员用于只读目标即 read_only_targets:secondaries。
健康检查和隔离
MySQL Router 作为无状态服务因此它依赖于 InnoDB Cluster 成员信息进行准确的路由。MGR 基于 Paxos 实现提供集群成员服务定义哪些服务器在线并参与组。通过利用该信息Router 避免连接到每个成员检查其状态。
然而当只读副本也是集群的一部分时该信息在组成员信息中不可用Router 无法依赖于该机制。同时集群成员间看到的可用性不同于 Router 视角成员信息可能不准确。
为解决这些挑战Router 实现了内置的隔离机制。
简而言之当 Router 由于新用户连接尝试连接目标端点失败时它会将该目标置于隔离状态。但目标不会永远停留在隔离状态在超时后Router 会对该服务器执行健康检查以确定是否可以从隔离池中移除它。
隔离机制在两个方面是可配置的
隔离阈值接受失败连接尝试的次数直到服务器被隔离。隔离服务器应该多频繁进行健康检查。
默认情况下这两个设置的值都是 1即失败连接会导致目标实例被隔离每秒对隔离实例进行健康检查以查看是否可以从隔离池中移除。
复制延迟
同步复制会导致复制延迟是常见问题需要考虑。如果实例延迟严重DBA 可能希望隐藏它等待它恢复同步然后再将它曝光给应用。
此外DBA 也可能希望隐藏读取副本
进行不断升级而不影响流入流量进行维护操作或配置更改而无需停止 MySQL在备份或生成报表时排除它以免影响其他查询将其配置为备份服务器排除任何读流量
与常规集群成员一样这可以通过指导 Router 不使用其标签来实现。
隐藏副本
要将实例从 Router 流量中隐藏可以使用内置的 _hidden 标签通过 .setInstanceOption() 命令很容易设置
mysqlsh-js cluster.setInstanceOption(rome5:3306, tag:_hidden, true)
该功能不限于副本次要实例也可以标记为隐藏。
总结
只读副本可以扩展读密集型工作负载的规模减轻其他集群成员的压力并提供更多的数据冗余。
感谢您使用 MySQL
更多技术文章请访问https://opensource.actionsky.com/
关于 SQLE
爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者支持多场景审核支持标准化上线流程原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
SQLE 获取
类型地址版本库https://github.com/actiontech/sqle文档https://actiontech.github.io/sqle-docs/发布信息https://github.com/actiontech/sqle/releases数据审核插件开发文档https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
