doc: 阅读mysql group replication相关文档
This commit is contained in:
wu xiangkai
@@ -2,6 +2,15 @@
|
||||
- [Group Replication Background](#group-replication-background)
|
||||
- [Replication Technologies](#replication-technologies)
|
||||
- [group replication](#group-replication)
|
||||
- [Group replication Use Cases](#group-replication-use-cases)
|
||||
- [Exmaple Use Cases](#exmaple-use-cases)
|
||||
- [Multi-primary and Single-Primary Modes](#multi-primary-and-single-primary-modes)
|
||||
- [Single-Primary Mode](#single-primary-mode)
|
||||
- [group\_replication\_enforce\_update\_everywhere\_checks](#group_replication_enforce_update_everywhere_checks)
|
||||
- [group\_replication\_consistency](#group_replication_consistency)
|
||||
- [Primary Election Algorithm](#primary-election-algorithm)
|
||||
- [Finding the Primary](#finding-the-primary)
|
||||
- [Multi-Primary Mode](#multi-primary-mode)
|
||||
|
||||
|
||||
# Mysql Group Replication
|
||||
@@ -80,3 +89,95 @@ Mysql Group Replication基于这些特性、抽象，实现了`multi-source upda
|
||||
|
||||
具体mysql group replication protocol的示意图如下所示：
|
||||
<img src="https://dev.mysql.com/doc/refman/8.4/en/images/gr-replication-diagram.png" style="width: 100%; max-width: 725px;">
|
||||
|
||||
### Group replication Use Cases
|
||||
Group Replication通过将系统状态复制到一组servers，能够创建一个有冗余性的容错系统。即使部分服务器随后fail，只要不是所有或majority发生故障，那么系统仍然可访问。
|
||||
|
||||
取决于group中故障server的数量不同，group可能出现性能下降或可拓展性降低的情况，但是整个系统仍然是可用的。server的故障是隔离和独立的，故障由group membership service来进行追踪，其基于分布式的failure detector，该detector能够在任何server自愿退出或异常退出group时发送信号。
|
||||
|
||||
在该系统中，无需进行server failover，且`multi-source update everywhere`的特性确保在单台server故障的场景下，update操作的执行仍然不会受阻。总而言之，mysql group replication保证了数据库服务是持续可用的。
|
||||
|
||||
需要认识到的是，即使数据库服务整体是可用的，当server非预期的退出时，连接到该故障server的clients仍然需要被重定向或故障转移到其他server。该处理流程不应由group replication来处理，而是应该由connector/load balancer/router/其他中间件来处理。
|
||||
|
||||
总之，mysql group replication提供了一个高可用、高弹性、可靠的mysql服务。
|
||||
|
||||
#### Exmaple Use Cases
|
||||
如下示例为group replication的典型用例场景：
|
||||
- `Elastic Replication`: 适用于高灵活度复制结构的环境，servers的数量需要可以动态的增加或缩减，并尽可能的减少副作用
|
||||
- `Highly Available Shards`: sharding是一种实现`write scale-out`的流行方案，可以使用mysql group replication来实现高可用shards，其中每个shard都被映射到一个replication group
|
||||
- `async source-replica replication的替代方案`: 在某些场景下，使用单个source server可能会造成单点争用，向整个group写入在特定场景下则更具有可拓展性（MGR支持多主模式部署，能够在group范围内缓解写压力）
|
||||
|
||||
### Multi-primary and Single-Primary Modes
|
||||
Group Replication可以在single-primary或multi-primary模式上工作。该group mode为一个group范围内的配置设置，通过system variable `group_replication_single_primary_mode`来指定，在所有group members中该variable必须都相同。
|
||||
- `ON`: 该值代表single-primary mode，也为变量的默认值
|
||||
- `OFF`: 该值代表multi-primary mode
|
||||
|
||||
> 在group中，所有的members其`group_replication_single_primary_mode`变量的值都必须相同
|
||||
|
||||
在group replication运行时，并无法手动修改`group_replication_single_primary_mode`的值，但是，在group replication运行时，可以使用`group_replication_switch_to_single_primary_mode()`和`group_replication_switch_to_multi_primary_mode()`方法来将group从一个模式切换到另一个模式。这些方法能够修改group的mode，并且确保数据的一致性和安全性。
|
||||
|
||||
不管处于哪种mode下，group replciation都不会处理client的failover，其必须由中间件framework例如`Mysql Router`/`proxy`/`connector`/`应用本身`来处理。
|
||||
|
||||
#### Single-Primary Mode
|
||||
在single-primary mode（group_replication_single_primary_mode=ON）时，group中只存在一个`primary server`（被设置为read/write mode）。group中所有其他的members都被设置为read-only mode（super_read_only=ON）。该primary server通常会引导整个集群的启动，所有其他加入到group中的servers都会识别到primary server并且自动被设置为read-only mode.
|
||||
|
||||
在single-primary mode时，group replication会强制只有一个server能够向group中写入，相比于multi-primary mode，single-primary mode的数据一致性检查可以不那么严格，DDL statements也无需额外谨慎的处理。
|
||||
|
||||
##### group_replication_enforce_update_everywhere_checks
|
||||
`group_replication_enforce_update_everywhere_checks`选项能够启用/禁用`对group的严格一致性检查`。当在single-primary mode下部署时，或将group的mode修改为single-primary mode时，该system variable的值必须被设置为`OFF`。
|
||||
|
||||
被指定为primary server的member可以按如下方式进行变更：
|
||||
- 如果该primary正常/非预期退出group，那么新primary的选举将会自动被触发
|
||||
- 可以通过`group_replication_set_as_primary()`方法将指定的member任命为primary
|
||||
- 如果使用`group_replication_switch_to_single_primary_mode()`方法将group从multi-primary mode切换为single-primary mode，那么将会自动选举出一个新的primary，或者可以通过方法指定primary
|
||||
|
||||
当new primary server被选举出后（自动或手动），岂会被自动设置为read/write状态；并且其他的group members将会变为`secondaries`，状态变为`read-only`，具体流程如下图所示：
|
||||
|
||||
<img src="https://dev.mysql.com/doc/refman/8.4/en/images/single-primary-election.png" style="width: 100%; max-width: 899px;">
|
||||
|
||||
当新primary被选中时，可能会存在部分变更的积压，这些变更已经在old primary中被应用，但是还没有被应用到new primary中。在这种情况下，直到new primary追上old primary之前，read/write transaction可能造成冲突并被回滚，而read-only transaction则可能会读取过时的数据。
|
||||
|
||||
通过group replication flow control mechanism，将会将fast member和slow member的差异最小化，在该机制被激活并经合理调优的情况下，可以有效降低该上述情况的发生概率。
|
||||
|
||||
##### group_replication_consistency
|
||||
可以通过该system variable来设置group的事务一致性级别，从而解决上述问题。
|
||||
- `BEFORE_ON_PRIMARY_FAILOVER`: 该值为默认值
|
||||
- 将该变量设置为`BEFORE_ON_PRIMARY_FAILOVER`或更高级别时，新选举出的primary将会暂时持有新事务，直到primary完成积压changes的applying
|
||||
|
||||
##### Primary Election Algorithm
|
||||
自动的primary member选举过程涉及每个member：每个member都会查看group的new view，对潜在的new primary members进行排序，并且选择最合适的member。在每个member的决策过程中，都会独立的在本地进行决策，决策遵循mysql server的primary election algorithm。
|
||||
> 由于所有的members都必须就决策达成一致，如果其他group member运行的mysql server版本较低时，members会调整其primary election algorithm，令其行为和group内最低版本的mysql server保持一致。
|
||||
|
||||
在members选举primary时，会考虑如下因素，考虑顺序如下：
|
||||
- 首先考虑的因素为`哪个member运行最低的mysql server version`，所有group members都会首先按照mysql server version进行排序
|
||||
- 如果存在多个members都运行最低的mysql server version，那么第二个考虑的因素为members中每个member的member weight，member weight由`group_replication_member_weight`进行指定
|
||||
- `group_replication_member_weight` system variable通过一个范围为`0-100`的数字进行指定，所有members的weight默认为50，该值设置越小，排序越靠后，值设置越大，排序越靠前
|
||||
- 通过weighting function可以令硬件更好的member优先级更高，或在primary计划维护时转移至特定的节点
|
||||
- 如果存在多个members运行相同的mysql server version，并且多个members都拥有最高的member weight，那么考虑的第三个因素则是每个member UUID的字典序，UUID通过`server_uuid` system variable来指定。拥有最小server UUID的member将会被选中为primary
|
||||
|
||||
##### Finding the Primary
|
||||
在部署在single-primary mode下时，如果要找出哪个server为当前的primary，可以通过`performance_schema.replication_group_members`表中的`MEMBER_ROLE`来进行判断，示例如下：
|
||||
```sql
|
||||
mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
|
||||
+-------------------------+-------------+
|
||||
| MEMBER_HOST | MEMBER_ROLE |
|
||||
+-------------------------+-------------+
|
||||
| remote1.example.com | PRIMARY |
|
||||
| remote2.example.com | SECONDARY |
|
||||
| remote3.example.com | SECONDARY |
|
||||
+-------------------------+-------------+
|
||||
```
|
||||
|
||||
#### Multi-Primary Mode
|
||||
在multi-primary mode（group_replication_single_primary_mode=OFF）下，没有member拥有特殊的role。任何member在加入group时都被设置为read/write模式，即使在并发情况下也能执行write transaction。
|
||||
|
||||
如果一个member停止接收write transactions，例如发生非预期的server exit，连接到member的clients将会被重定向或failover到其他的任一处于read/write模式的member。group replciation本身并不会处理client-side failover，可以使用中间件来处理，例如mysql router。
|
||||
|
||||
<img src="https://dev.mysql.com/doc/refman/8.4/en/images/multi-primary.png" style="width: 100%; max-width: 899px;">
|
||||
|
||||
group replication是一个最终一致性的系统，其代表当incoming traffic降低或停止时，所有group members都会包含相同的数据内容。当traffic流动时，某些members对transactions进行externalized的时机可能位于另一些members之前。尤其是某些member的写吞吐可能低于其他member，导致连接到该member的client可能读取到过时数据。
|
||||
|
||||
在multi-primary mode下，较慢的member也可能会积累过多的待认证事务和待applying的事务，导致冲突和认证失败的风险更高。为了限制该问题，可以采用group replication的flow control mechansim机制来最小化fast member和slow member的差异。
|
||||
|
||||
如果想要为group中的每个事务提供一致性保证，可以使用`group_replication_consistency`系统变量实现。可以根据group中工作负载和数据读写的优先级来选择合适的设置，同时应考虑提升一致性所引入的同步操作对性能带来的影响。可以针对独立的session来设置该系统变量，从而保护对并发性敏感的事务。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user