基于案例分析 MySQL Group Replication 的故障检测流程
故障检测（Failure Detection）是 Group Replication 的一个核心功能模块，通过它可以及时识别集群中的故障节点，并将故障节点从集群中剔除掉。如果不将故障节点及时剔除的话，一方面会影响集群的性能，另一方面还会阻止集群拓扑的变更。
下面结合一个具体的案例，分析 Group Replication 的故障检测流程。
除此之外，本文还会分析以下问题。
- 当出现网络分区时，对于少数派节点，会有什么影响？
- 什么是 XCom Cache？如何预估 XCom Cache 的大小？
- 在线上，为什么 group_replication_member_expel_timeout 不宜设置过大？
案例
以下是测试集群的拓扑，多主模式。
| 主机名 | IP | 角色 |
| node1 | 192.168.244.10 | PRIMARY |
| node2 | 192.168.244.20 | PRIMARY |
| node3 | 192.168.244.30 | PRIMARY |
本次测试主要包括两步：
- 模拟网络分区，看它对集群各节点的影响。
- 恢复网络连接，看看各节点又是如何反应的。
模拟网络分区
首先模拟网络分区故障，在 node3 上执行。
# iptables -A INPUT -p tcp -s 192.168.244.10 -j DROP
# iptables -A OUTPUT -p tcp -d 192.168.244.10 -j DROP
# iptables -A INPUT -p tcp -s 192.168.244.20 -j DROP
# iptables -A OUTPUT -p tcp -d 192.168.244.20 -j DROP
# date "+%Y-%m-%d %H:%M:%S"
2022-07-31 13:03:01
其中，iptables 命令会断开 node3 与 node1、node2 之间的网络连接。date 记录了命令执行的时间。
命令执行完 5s（这个时间是固定的，在源码中通过 DETECTOR_LIVE_TIMEOUT 指定），各个节点开始响应（从各节点的日志中可以观察到这一点）
首先看看 node1 的日志及集群状态。
2022-07-31T13:03:07.582519-00:00 0 [Warning] [MY-011493] [Repl] Plugin group_replication reported: 'Member with address 192.168.244.30:3306 has become unreachable.'
mysql> select member_id,member_host,member_port,member_state,member_role from performance_schema.replication_group_members;
+--------------------------------------+----------------+-------------+--------------+-------------+
| member_id | member_host | member_port | member_state | member_role |
+--------------------------------------+----------------+-------------+--------------+-------------+
| 207db264-0192-11ed-92c9-02001700754e | 192.168.244.10 | 3306 | ONLINE | PRIMARY |
| 2cee229d-0192-11ed-8eff-02001700f110 | 192.168.244.20 | 3306 | ONLINE | PRIMARY |
| 4cbfdc79-0192-11ed-8b01-02001701bd0a | 192.168.244.30 | 3306 | UNREACHABLE | PRIMARY |
+--------------------------------------+----------------+-------------+--------------+-------------+
3 rows in set (0.00 sec)
从 node1，node2 的角度来看，此时 node3 处于 UNREACHABLE 状态。
接下来看看 node3 的。
2022-07-31T13:03:07.690416-00:00 0 [Warning] [MY-011493] [Repl] Plugin group_replication reported: 'Member with address 192.168.244.10:3306 has become unreachable.'
2022-07-31T13:03:07.690492-00:00 0 [Warning] [MY-011493] [Repl] Plugin group_replication reported: 'Member with address 192.168.244.20:3306 has become unreachable.'
2022-07-31T13:03:07.690504-00:00 0 [ERROR] [MY-011495] [Repl] Plugin group_replication reported: 'This server is not able to reach a majority of members in the group. This server will now block all updates. The server will remain blocked until contact with the majority is restored. It is possible to use group_replication_force_members to force a new group membership.'
mysql> select member_id,member_host,member_port,member_state,member_role from performance_schema.replication_group_members;
+--------------------------------------+----------------+-------------+--------------+-------------+
| member_id | member_host | member_port | member_state | member_role |
+--------------------------------------+----------------+-------------+--------------+-------------+
| 207db264-0192-11ed-92c9-02001700754e | 192.168.244.10 | 3306 | UNREACHABLE | PRIMARY |
| 2cee229d-0192-11ed-8eff-02001700f110 | 192.168.244.20 | 3306 | UNREACHABLE | PRIMARY |
| 4cbfdc79-0192-11ed-8b01-02001701bd0a | 192.168.244.30 | 3306 | ONLINE | PRIMARY |
+--------------------------------------+----------------+-------------+--------------+-------------+
3 rows in set (0.00 sec)
从 node3 的角度来看，此时 node1，node2 处于 UNREACHABLE 状态。
三个节点，只有一个节点处于 ONLINE 状态，不满足组复制的多数派原则。此时，node3 只能查询，写操作会被阻塞。
mysql> select * from slowtech.t1 where id=1;
+----+------+
| id | c1 |
+----+------+
| 1 | a |
+----+------+
1 row in set (0.00 sec)
mysql> delete from slowtech.t1 where id=1;
阻塞中。。。
又过了 16s（这里的 16s，实际上与 group_replication_member_expel_timeout 参数有关），node1、node2 会将 node3 驱逐出（expel）集群。此时，集群只有两个节点组成。
看看 node1 的日志及集群状态。
2022-07-31T13:03:23.576960-00:00 0 [Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: 192.168.244.30:3306'
2022-07-31T13:03:23.577091-00:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to 192.168.244.10:3306, 192.168.244.20:3306 on view 16592724636525403:3.'
mysql> select member_id,member_host,member_port,member_state,member_role from performance_schema.replication_group_members;
+--------------------------------------+----------------+-------------+--------------+-------------+
| member_id | member_host | member_port | member_state | member_role |
+--------------------------------------+----------------+-------------+--------------+-------------+
| 207db264-0192-11ed-92c9-02001700754e | 192.168.244.10 | 3306 | ONLINE | PRIMARY |
| 2cee229d-0192-11ed-8eff-02001700f110 | 192.168.244.20 | 3306 | ONLINE | PRIMARY |
+--------------------------------------+----------------+-------------+--------------+-------------+
2 rows in set (0.00 sec)
再来看看 node3 的，日志没有新的输出，节点状态也没变化。
mysql> select member_id,member_host,member_port,member_state,member_role from performance_schema.replication_group_members;
+--------------------------------------+----------------+-------------+--------------+-------------+
| member_id | member_host | member_port | member_state | member_role |
+--------------------------------------+----------------+-------------+--------------+-------------+
| 207db264-0192-11ed-92c9-02001700754e | 192.168.244.10 | 3306 | UNREACHABLE | PRIMARY |
| 2cee229d-0192-11ed-8eff-02001700f110 | 192.168.244.20 | 3306 | UNREACHABLE | PRIMARY |
| 4cbfdc79-0192-11ed-8b01-02001701bd0a | 192.168.244.30 | 3306 | ONLINE | PRIMARY |
+--------------------------------------+----------------+-------------+--------------+-------------+
3 rows in set (0.00 sec)
恢复网络连接
接下来我们恢复 node3 与 node1、node2 之间的网络连接。
# iptables -F
# date "+%Y-%m-%d %H:%M:%S"
2022-07-31 13:07:30
首先看看 node3 的日志
2022-07-31T13:07:30.464179-00:00 0 [Warning] [MY-011494] [Repl] Plugin group_replication reported: 'Member with address 192.168.244.10:3306 is reachable again.'
2022-07-31T13:07:30.464226-00:00 0 [Warning] [MY-011494] [Repl] Plugin group_replication reported: 'Member with address 192.168.244.20:3306 is reachable again.'
2022-07-31T13:07:30.464239-00:00 0 [Warning] [MY-011498] [Repl] Plugin group_replication reported: 'The member has resumed contact with a majority of the members in the group. Regular operation is restored and transactions are unblocked.'
2022-07-31T13:07:37.458761-00:00 0 [ERROR] [MY-011505] [Repl] Plugin group_replication reported: 'Member was expelled from the group due to network failures, changing member status to ERROR.'
2022-07-31T13:07:37.459011-00:00 0 [Warning] [MY-011630] [Repl] Plugin group_replication reported: 'Due to a plugin error, some transactions were unable to be certified and will now rollback.'
2022-07-31T13:07:37.459037-00:00 0 [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'
2022-07-31T13:07:37.459431-00:00 31 [ERROR] [MY-011615] [Repl] Plugin group_replication reported: 'Error while waiting for conflict detection procedure to finish on session 31'
2022-07-31T13:07:37.459478-00:00 31 [ERROR] [MY-010207] [Repl] Run function 'before_commit' in plugin 'group_replication' failed
2022-07-31T13:07:37.459811-00:00 33 [System] [MY-011565] [Repl] Plugin group_replication reported: 'Setting super_read_only=ON.'
2022-07-31T13:07:37.465738-00:00 34 [System] [MY-013373] [Repl] Plugin group_replication reported: 'Started auto-rejoin procedure attempt 1 of 3'
2022-07-31T13:07:37.496466-00:00 0 [System] [MY-011504] [Repl] Plugin group_replication reported: 'Group membership changed: This member has left the group.'
2022-07-31T13:07:37.498813-00:00 36 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_applier' executed'. Previous state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 351, master_bind=''. New state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''.
2022-07-31T13:07:39.653028-00:00 34 [System] [MY-013375] [Repl] Plugin group_replication reported: 'Auto-rejoin procedure attempt 1 of 3 finished. Member was able to join the group.'
2022-07-31T13:07:40.653484-00:00 0 [System] [MY-013471] [Repl] Plugin group_replication reported: 'Distributed recovery will transfer data using: Incremental recovery from a group donor'
2022-07-31T13:07:40.653822-00:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to 192.168.244.10:3306, 192.168.244.20:3306, 192.168.244.30:3306 on view 16592724636525403:4.'
2022-07-31T13:07:40.670530-00:00 46 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='192.168.244.20', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''.
2022-07-31T13:07:40.682990-00:00 47 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2022-07-31T13:07:40.687566-00:00 47 [System] [MY-010562] [Repl] Slave I/O thread for channel 'group_replication_recovery': connected to master 'repl@192.168.244.20:3306',replication started in log 'FIRST' at position 4
2022-07-31T13:07:40.717851-00:00 46 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='192.168.244.20', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''.
2022-07-31T13:07:40.732297-00:00 0 [System] [MY-011490] [Repl] Plugin group_replication reported: 'This server was declared online within the replication group.'
2022-07-31T13:07:40.732511-00:00 53 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.'
日志的输出包括两部分，以空格为分界线。
1. 当网络连接恢复后，node3 与 node1、node2 重新建立起了连接，发现自己已经被集群驱逐，于是节点进入到 ERROR 状态。
mysql> select member_id,member_host,member_port,member_state,member_role from performance_schema.replication_group_members;
+--------------------------------------+----------------+-------------+--------------+-------------+
| member_id | member_host | member_port | member_state | member_role |
+--------------------------------------+----------------+-------------+--------------+-------------+
| 4cbfdc79-0192-11ed-8b01-02001701bd0a | 192.168.244.30 | 3306 | ERROR | |
+--------------------------------------+----------------+-------------+--------------+-------------+
1 row in set (0.00 sec)
节点进入到 ERROR 状态，会自动设置为只读，即日志中看到的 super_read_only=ON。注意，ERROR 状态的节点设置为只读是默认行为，与后面提到的 group_replication_exit_state_action 参数无关。
2. 如果group_replication_autorejoin_tries不为 0，对于 ERROR 状态的节点，会自动重试，重新加入集群（auto-rejoin）。重试的次数由 group_replication_autorejoin_tries 决定，从 MySQL 8.0.21 开始，默认为 3。重试的时间间隔是 5min。重试成功后，会进入到分布式恢复阶段。
接下来看看 node1 的日志。
2022-07-31T13:07:39.555613-00:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to 192.168.244.10:3306, 192.168.244.20:3306, 192.168.244.30:3306 on view 16592724636525403:4.'
2022-07-31T13:07:40.732568-00:00 0 [System] [MY-011492] [Repl] Plugin group_replication reported: 'The member with address 192.168.244.30:3306 was declared online within the replication group.'
node3 又重新加入到集群中。
故障检测流程
结合上面的案例，我们来看看 Group Repliction 的故障检测流程。
集群中每个节点都会定期（每秒 1 次）向其它节点发送心跳信息。如果在 5s 内（固定值，无参数调整）没有收到其它节点的心跳信息，则会将该节点标记为可疑节点，同时会将该节点的状态设置为 UNREACHABLE 。如果集群中有等于或超过 1/2 的节点显示为 UNREACHABLE ，则该集群不能对外提供写服务。
如果在group_replication_member_expel_timeout（从 MySQL 8.0.21 开始，该参数的默认值为 5，单位 s，最大可设置值为3600，即 1 小时）时间内，可疑节点恢复正常，则会直接应用 XCom Cache 中的消息。XCom Cache 的大小由group_replication_message_cache_size 决定，默认是 1G。
如果在group_replication_member_expel_timeout时间内，可疑节点没有恢复正常，则会被驱逐出集群。
而少数派节点呢，不会自动离开集群，它会一直维持当前的状态，直到：
- 网络恢复正常。
- 达到 group_replication_unreachable_majority_timeout 的限制。注意，该参数的起始计算时间是连接断开 5s 之后，不是可疑节点被驱逐出集群的时间。该参数默认为 0。
无论哪种情况，都会触发：
节点状态从 ONLINE 切换到 ERROR 。
回滚当前被阻塞的写操作。
mysql> delete from slowtech.t1 where id=1;
ERROR 3100 (HY000): Error on observer while running replication hook 'before_commit'.
ERROR 状态的节点会自动设置为只读。
如果group_replication_autorejoin_tries不为 0，对于 ERROR 状态的节点，会自动重试，重新加入集群（auto-rejoin）。
如果group_replication_autorejoin_tries为 0 或重试失败，则会执行 group_replication_exit_state_action 指定的操作。可选的操作有：
READ_ONLY：只读模式。在这种模式下，会将 super_read_only 设置为 ON。默认值。
OFFLINE_MODE：离线模式。在这种模式下，会将 offline_mode 和 super_read_only 设置为 ON，此时，只有CONNECTION_ADMIN（SUPER）权限的用户才能登陆，普通用户不能登录。
# mysql -h 192.168.244.3. -P 3306 -ut1 -p123456
ERROR 3032 (HY000): The server is currently in offline mode
ABORT_SERVER：关闭实例。
XCom Cache
XCom Cache 是 XCom 使用的消息缓存，用来缓存集群节点之间交换的消息。缓存的消息是共识协议的一部分。如果网络不稳定，可能会出现节点失联的情况。
如果节点在一定时间（由 group_replication_member_expel_timeout 决定）内恢复正常，它会首先应用 XCom Cache 中的消息。如果 XCom Cache 没有它需要的所有消息，这个节点会被驱逐出集群。驱逐出集群后，如果 group_replication_autorejoin_tries 不为 0，它会重新加入集群（auto-rejoin）。
重新加入集群会使用 Distributed Recovery 补齐差异数据。相比较直接使用 XCom Cache 中的消息，通过 Distributed Recovery 加入集群需要的时间相对较长，过程也较复杂，并且集群的性能也会受到影响。
所以，我们在设置 XCom Cache 的大小时，需预估 group_replication_member_expel_timeout + 5s 这段时间内的内存使用量。如何预估，后面会介绍相关的系统表。
下面我们模拟下 XCom Cache 不足的场景。
1. 将group_replication_message_cache_size调整为最小值（128 MB），重启组复制使其生效。
mysql> set global group_replication_message_cache_size=134217728;
Query OK, 0 rows affected (0.00 sec)
mysql> stop group_replication;
Query OK, 0 rows affected (4.15 sec)
mysql> start group_replication;
Query OK, 0 rows affected (3.71 sec)
2. 将group_replication_member_expel_timeout调整为 3600。这样，我们才有充足的时间进行测试。
mysql> set global group_replication_member_expel_timeout=3600;
Query OK, 0 rows affected (0.01 sec)
3. 断开 node3 与node1、node2 之间的网络连接。
# iptables -A INPUT -p tcp -s 192.168.244.10 -j DROP
# iptables -A OUTPUT -p tcp -d 192.168.244.10 -j DROP
# iptables -A INPUT -p tcp -s 192.168.244.20 -j DROP
# iptables -A OUTPUT -p tcp -d 192.168.244.20 -j DROP
4. 反复执行大事务。
mysql> insert into slowtech.t1(c1) select c1 from slowtech.t1 limit 1000000;
Query OK, 1000000 rows affected (10.03 sec)
Records: 1000000 Duplicates: 0 Warnings: 0
5. 观察错误日志。
如果 node1 或 node2 的错误日志中提示以下信息，则意味着 node3 需要的消息已经从 XCom Cache 中逐出了。
[Warning] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Messages that are needed to recover node 192.168.244.30:33061 have been evicted from the message cache. Consider resizing the maximum size of the cache by setting group_replication_message_cache_size.'
6. 查看系统表。
除了错误日志，我们还可以通过系统表来判断 XCom Cache 的使用情况。
mysql> select * from performance_schema.memory_summary_global_by_event_name where event_name like "%GCS_XCom::xcom_cache%"\G
*************************** 1. row ***************************
EVENT_NAME: memory/group_rpl/GCS_XCom::xcom_cache
COUNT_ALLOC: 23678
COUNT_FREE: 22754
SUM_NUMBER_OF_BYTES_ALLOC: 154713397
SUM_NUMBER_OF_BYTES_FREE: 28441492
LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 924
HIGH_COUNT_USED: 20992
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 126271905
HIGH_NUMBER_OF_BYTES_USED: 146137294
1 row in set (0.00 sec)
其中，
- COUNT_ALLOC：缓存过的消息数量。
- COUNT_FREE：从缓存中删除的消息数量。
- CURRENT_COUNT_USED：当前正在缓存的消息数量，等于 COUNT_ALLOC - COUNT_FREE。
- SUM_NUMBER_OF_BYTES_ALLOC：分配的内存大小。
- SUM_NUMBER_OF_BYTES_FREE：被释放的内存大小。
- CURRENT_NUMBER_OF_BYTES_USED：当前正在使用的内存大小，等于 SUM_NUMBER_OF_BYTES_ALLOC - SUM_NUMBER_OF_BYTES_FREE。
- LOW_COUNT_USED，HIGH_COUNT_USED：CURRENT_COUNT_USED 的历史最小值和最大值。
- LOW_NUMBER_OF_BYTES_USED，HIGH_NUMBER_OF_BYTES_USED：CURRENT_NUMBER_OF_BYTES_USED 的历史最小值和最大值。
如果断开连接之后，在反复执行大事务的过程中，发现 COUNT_FREE 发生了变化，同样意味着 node3 需要的消息已经从 XCom Cache 中驱逐了。
7. 恢复 node3 与 node1、node2 之间的网络连接。
在 group_replication_member_expel_timeout 期间，网络恢复了，而 node3 需要的消息在 XCom Cache 中不存在了，则 node3 同样会被驱逐出集群。以下是这种场景下 node3 的错误日志。
[ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Node 0 is unable to get message {4aec99ca 7562 0}, since the group is too far ahead. Node will now exit.'
[ERROR] [MY-011505] [Repl] Plugin group_replication reported: 'Member was expelled from the group due to network failures, changing member status to ERROR.'
[ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'
[System] [MY-011565] [Repl] Plugin group_replication reported: 'Setting super_read_only=ON.'
[System] [MY-013373] [Repl] Plugin group_replication reported: 'Started auto-rejoin procedure attempt 1 of 3'
注意事项
如果集群中存在 UNREACHABLE 的节点，会有以下限制和不足：
- 不能调整集群的拓扑，包括添加和删除节点。
- 在单主模式下，如果 Primary 节点出现故障了，无法选择新主。
- 如果 Group Replication 的一致性级别等于 AFTER 或 BEFORE_AND_AFTER，则写操作会一直等待，直到 UNREACHABLE 节点 ONLINE 并应用该操作。
- 集群吞吐量会下降。如果是单主模式，可将 group_replication_paxos_single_leader （MySQL 8.0.27 引入的）设置为 ON 解决这个问题。
所以，在线上 group_replication_member_expel_timeout 不宜设置过大。
参考资料
[1] Extending replication instrumentation: account for memory used in XCom
[2] MySQL Group Replication - Default response to network partitions has changed
[3] No Ping Will Tear Us Apart - Enabling member auto-rejoin in Group Replication
基于案例分析 MySQL Group Replication 的故障检测流程的更多相关文章
- Mysql 5.7 基于组复制(MySQL Group Replication) - 运维小结
之前介绍了Mysq主从同步的异步复制(默认模式).半同步复制.基于GTID复制.基于组提交和并行复制 (解决同步延迟),下面简单说下Mysql基于组复制(MySQL Group Replication ...
- Paxos算法与Zookeeper分析,zab (zk)raft协议(etcd) 8. 与Galera及MySQL Group replication的比较
mit 分布式论文集 https://github.com/feixiao/Distributed-Systems wiki上描述的几种都明白了就出师了 raft 和 zab 是类似的,都是1.先选举 ...
- MySQL Group Replication 技术点
mysql group replication,组复制,提供了多写(multi-master update)的特性,增强了原有的mysql的高可用架构.mysql group replication基 ...
- MySQL Group Replication配置
MySQL Group Replication简述 MySQL 组复制实现了基于复制协议的多主更新(单主模式). 复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事 ...
- Mysql Group Replication 简介及单主模式组复制配置【转】
一 Mysql Group Replication简介 Mysql Group Replication(MGR)是一个全新的高可用和高扩张的MySQL集群服务. 高一致性,基于原生复制及p ...
- MySQL Group Replication 介绍
2016-12-12,一个重要的日子,mysql5.7.17 GA版发布,正式推出Group Replication(组复制) 插件,通过这个插件增强了MySQL原有的高可用方案(原有的Replica ...
- Percona XtraDB Cluster vs Galera Cluster vs MySQL Group Replication
Percona XtraDB Cluster vs Galera Cluster vs MySQL Group Replication Overview Galera Cluster 由 Coders ...
- MySQL group replication介绍
“MySQL group replication” group replication是MySQL官方开发的一个开源插件,是实现MySQL高可用集群的一个工具.第一个GA版本正式发布于MySQL5.7 ...
- mysql group replication观点及实践
一:个人看法 Mysql Group Replication 随着5.7发布3年了.作为技术爱好者.mgr 是继 oracle database rac 之后. 又一个“真正” 的群集,怎么做到“ ...
随机推荐
- tty的crash分析
crash> btPID: 410629 TASK: ffff883fea379fa0 CPU: 10 COMMAND: "jupyter-lab"#0 [ffff8823c ...
- React报错之Invalid hook call
正文从这开始~ 总览 导致"Invalid hook call. Hooks can only be called inside the body of a function compone ...
- 概述：基于事件的优化方法 / 事件驱动优化 / Event-Based Optimization / EBO
大家好,我是月出 本文基于这篇综述,介绍了 事件驱动优化(Event-Based Optimization, EBO). 事件驱动优化,是一种建模现实场景.做优化的思路,理论和 MDP / 强化学习很 ...
- 痞子衡嵌入式：在i.MXRT启动头FDCB里使能串行NOR Flash的QPI/OPI模式
大家好,我是痞子衡,是正经搞技术的痞子.今天痞子衡给大家介绍的是在FDCB里使能串行NOR Flash的QPI/OPI模式. 我们知道 Flash 读时序里有五大子序列 CMD + ADDR + MO ...
- npm 和 maven 使用 Nexus3 私服 | 前后端一起学
前文<Docker 搭建 Nexus3 私服 >介绍了在 docker 环境下安装 nexus3 以及 nexus3 的基本操作和管理,本文分别介绍 npm(前端)和 maven(后端)如 ...
- noip2018提高组初赛试题
一.单项选择题(共 10 题,每题 2 分,共计 20 分: 每题有且仅有一个正确选项) \2. 下列属于解释执行的程序设计语言是( ). A. C B. C++ C. Pascal D. Pytho ...
- 数据库基础操作 part1
初识数据库 数据库相关概念 数据库管理软件: 本质就是一个C/S架构的套接字程序 服务端套接字 客户端套接字 操作系统: Linux 操作系统: 随意 计算机(本地文件) 计算机硬件 应用流程: 服务 ...
- KingbaseES 多列分区的方法与性能
前言 对于多列分区,可以选择单级多列的范围分区,也可以选择范围加子分区的方式.但二者在不同场景下对于性能是有差异的,这里的性能差异主要是分区裁剪引起的差异. 例子 创建两张分区表,采取不同的分区策略: ...
- 用【Unity】中的【3D Object】画【数学函数】图形 —— 正弦函数... { }
效果 场景搭建 创建一个空物体,并将其命名为 "GameManager",并[Reset]它 创建一个 "Sphere",并将其[Scale]设置为(0.1,0 ...
- MQ的消息丢失/重复/积压的问题解决
在我们实际的开发过程中,我们肯定会用到MQ中间件,常见的MQ中间件有kafka,RabbitMQ,RocketMQ.在使用的过程中,我们必须要考虑这样一个问题,在使用MQ的时候,我们怎么确保消息100 ...