jjzjj

基于案例分析 MySQL Group Replication 的故障检测流程

爱学习的Victor 2023-03-28 原文
故障检测（Failure Detection）是 Group Replication 的一个核心功能模块，通过它可以及时识别集群中的故障节点，并将故障节点从集群中剔除掉。如果不将故障节点及时剔除的话，一方面会影响集群的性能，另一方面还会阻止集群拓扑的变更。

下面结合一个具体的案例，分析 Group Replication 的故障检测流程。

除此之外，本文还会分析以下问题。

  1. 当出现网络分区时，对于少数派节点，会有什么影响？
  2. 什么是 XCom Cache？如何预估 XCom Cache 的大小？
  3. 在线上，为什么 group_replication_member_expel_timeout 不宜设置过大？

案例

以下是测试集群的拓扑，多主模式。

主机名 IP 角色
node1 192.168.244.10 PRIMARY
node2 192.168.244.20 PRIMARY
node3 192.168.244.30 PRIMARY
本次测试主要包括两步：

  1. 模拟网络分区，看它对集群各节点的影响。
  2. 恢复网络连接，看看各节点又是如何反应的。

模拟网络分区

首先模拟网络分区故障，在 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 参数无关。

  1. 如果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. 集群中每个节点都会定期（每秒 1 次）向其它节点发送心跳信息。如果在 5s 内（固定值，无参数调整）没有收到其它节点的心跳信息，则会将该节点标记为可疑节点，同时会将该节点的状态设置为 UNREACHABLE 。如果集群中有等于或超过 1/2 的节点显示为 UNREACHABLE ，则该集群不能对外提供写服务。

  2. 如果在group_replication_member_expel_timeout（从 MySQL 8.0.21 开始，该参数的默认值为 5，单位 s，最大可设置值为3600，即 1 小时）时间内，可疑节点恢复正常，则会直接应用 XCom Cache 中的消息。XCom Cache 的大小由group_replication_message_cache_size 决定，默认是 1G。

  3. 如果在group_replication_member_expel_timeout时间内，可疑节点没有恢复正常，则会被驱逐出集群。

  4. 而少数派节点呢，不会自动离开集群，它会一直维持当前的状态，直到：

    • 网络恢复正常。
    • 达到 group_replication_unreachable_majority_timeout 的限制。注意，该参数的起始计算时间是连接断开 5s 之后，不是可疑节点被驱逐出集群的时间。该参数默认为 0。
  5. 无论哪种情况，都会触发：

    • 节点状态从 ONLINE 切换到 ERROR 。

    • 回滚当前被阻塞的写操作。

      mysql> delete from slowtech.t1 where id=1; ERROR 3100 (HY000): Error on observer while running replication hook 'before_commit'.
  6. ERROR 状态的节点会自动设置为只读。

  7. 如果group_replication_autorejoin_tries不为 0，对于 ERROR 状态的节点，会自动重试，重新加入集群（auto-rejoin）。

  8. 如果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)
  1. 将group_replication_member_expel_timeout调整为 3600。这样，我们才有充足的时间进行测试。
mysql> set global group_replication_member_expel_timeout=3600; Query OK, 0 rows affected (0.01 sec)
  1. 断开 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
  1. 反复执行大事务。
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
  1. 观察错误日志。
如果 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.'
  1. 查看系统表。
除了错误日志，我们还可以通过系统表来判断 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 中驱逐了。

  1. 恢复 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 的节点，会有以下限制和不足：

  1. 不能调整集群的拓扑，包括添加和删除节点。
  2. 在单主模式下，如果 Primary 节点出现故障了，无法选择新主。
  3. 如果 Group Replication 的一致性级别等于 AFTER 或 BEFORE_AND_AFTER，则写操作会一直等待，直到 UNREACHABLE 节点 ONLINE 并应用该操作。
  4. 集群吞吐量会下降。如果是单主模式，可将 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: https://dev.mysql.com/blog-archive/extending-replication-instrumentation-account-for-memory-used-in-xcom/

[2] MySQL Group Replication - Default response to network partitions has changed: https://dev.mysql.com/blog-archive/mysql-group-replication-default-response-to-network-partitions-has-changed/

[3] No Ping Will Tear Us Apart - Enabling member auto-rejoin in Group Replication: https://dev.mysql.com/blog-archive/no-ping-will-tear-us-apart-enabling-member-auto-rejoin-in-group-replication/

案例分析ReplicationreplicationgroupmemberMySQLGroupReplicationMySQL数据库

有关基于案例分析 MySQL Group Replication 的故障检测流程的更多相关文章

  1. ruby - RuntimeError(自动加载常量 Apps 多线程时检测到循环依赖 - 2

    我收到这个错误:RuntimeError(自动加载常量Apps时检测到循环依赖当我使用多线程时。下面是我的代码。为什么会这样？我尝试多线程的原因是因为我正在编写一个HTML抓取应用程序。对Nokogiri::HTML(open())的调用是一个同步阻塞调用，需要1秒才能返回，我有100,000多个页面要访问，所以我试图运行多个线程来解决这个问题。有更好的方法吗？classToolsController0)app.website=array.join(',')putsapp.websiteelseapp.website="NONE"endapp.saveapps=Apps.order("

  2. 叮咚买菜基于 Apache Doris 统一 OLAP 引擎的应用实践 - 2

    导读：随着叮咚买菜业务的发展，不同的业务场景对数据分析提出了不同的需求，他们希望引入一款实时OLAP数据库，构建一个灵活的多维实时查询和分析的平台，统一数据的接入和查询方案，解决各业务线对数据高效实时查询和精细化运营的需求。经过调研选型，最终引入ApacheDoris作为最终的OLAP分析引擎，Doris作为核心的OLAP引擎支持复杂地分析操作、提供多维的数据视图，在叮咚买菜数十个业务场景中广泛应用。作者｜叮咚买菜资深数据工程师韩青叮咚买菜创立于2017年5月，是一家专注美好食物的创业公司。叮咚买菜专注吃的事业，为满足更多人“想吃什么”而努力，通过美好食材的供应、美好滋味的开发以及美食品牌的孵

  3. 基于C#实现简易绘图工具【100010177】 - 2

    C#实现简易绘图工具一.引言实验目的:通过制作窗体应用程序(C#画图软件),熟悉基本的窗体设计过程以及控件设计,事件处理等,熟悉使用C#的winform窗体进行绘图的基本步骤,对于面向对象编程有更加深刻的体会.Tutorial任务设计一个具有基本功能的画图软件**·包括简单的新建文件,保存,重新绘图等功能**·实现一些基本图形的绘制,包括铅笔和基本形状等,学习橡皮工具的创建**·设计一个合理舒适的UI界面**注明:你可能需要先了解一些关于winform窗体应用程序绘图的基本知识,以及关于GDI+类和结构的知识二.实验环境Windows系统下的visualstudio2017C#窗体应用程序三.

  4. 「Python｜Selenium｜场景案例」如何定位iframe中的元素？ - 2

    本文主要介绍在使用Selenium进行自动化测试或者任务时，对于使用了iframe的页面，如何定位iframe中的元素文章目录场景描述解决方案具体代码场景描述当我们在使用Selenium进行自动化测试的时候，可能会遇到一些界面或者窗体是使用HTML的iframe标签进行承载的。对于iframe中的标签，如果直接查找是无法找到的，会抛出没有找到元素的异常。比如近在咫尺的例子就是，CSDN的登录窗体就是使用的iframe，大家可以尝试通过F12开发者模式查看到的tag_name,class_name,id或者xpath来定位中的页面元素，会抛出NoSuchElementException异常。解决

  5. kvm虚拟机安装centos7基于ubuntu20.04系统 - 2

    需求：要创建虚拟机，就需要给他提供一个虚拟的磁盘，我们就在/opt目录下创建一个10G大小的raw格式的虚拟磁盘CentOS-7-x86_64.raw命令格式：qemu-imgcreate-f磁盘格式磁盘名称磁盘大小qemu-imgcreate-f磁盘格式-o?1.创建磁盘qemu-imgcreate-fraw/opt/CentOS-7-x86_64.raw10G执行效果#ls/opt/CentOS-7-x86_64.raw2.安装虚拟机使用virt-install命令，基于我们提供的系统镜像和虚拟磁盘来创建一个虚拟机，另外在创建虚拟机之前，提前打开vnc客户端，在创建虚拟机的时候，通过vnc

  6. ruby - 检测由 RSpec、Ruby 运行的代码 - 2

    我想知道我的代码是否在rspec下运行。这可能吗？原因是我正在加载一些错误记录器，这些记录器在测试期间会被故意错误(expect{x}.toraise_error)弄得乱七八糟。我查看了我的ENV变量，没有(明显的)测试环境变量的迹象。 最佳答案 在spec_helper.rb的开头添加:ENV['RACK_ENV']='test'现在您可以在代码中检查RACK_ENV是否经过测试。 关于ruby-检测由RSpec、Ruby运行的代码，我们在StackOverflow上找到一个类似的问题

  7. ruby - 使用 Ruby Daemons gem 检测停止 - 2

    我正在使用rubydaemongem。想知道如何向停止操作添加一些额外的步骤？希望我能检测到停止被调用，并向其添加一些额外的代码。任何人都知道我如何才能做到这一点？ 最佳答案 查看守护程序gem代码，它似乎没有用于此目的的明显扩展点。但是，我想知道(在守护进程中)您是否可以捕获守护进程在发生“停止”时发送的KILL/TERM信号...？trap("TERM")do#executeyourextracodehereend或者你可以安装一个at_exit钩子(Hook):-at_exitdo#executeyourextracodehe

  8. ruby-on-rails - (Ruby,Rails) 基于角色的身份验证和用户管理...？ - 2

    我正在寻找用于Rails的优质管理插件。似乎大多数现有的插件/gem(例如“restful_authentication”、“acts_as_authenticated”)都围绕着self注册等展开。但是，我正在寻找一种功能齐全的基于管理/管理角色的解决方案——但不是简单地附加到另一个非基于角色的解决方案。如果我找不到，我想我会自己动手......只是不想重新发明轮子。 最佳答案 RyanBates最近做了两个关于授权的railscast(注意身份验证和授权之间的区别；身份验证检查用户是否如她所说的那样，授权检查用户是否有权访问资源

  9. ruby - 在 Rakefile 中动态生成 Rake 测试任务(基于现有的测试文件) - 2

    我正在根据Rakefile中的现有测试文件动态生成测试任务。假设您有各种以模式命名的单元测试文件test_.rb.所以我正在做的是创建一个以“测试”命名空间内的文件名命名的任务。使用下面的代码，我可以用raketest:调用所有测试require'rake/testtask'task:default=>'test:all'namespace:testdodesc"Runalltests"Rake::TestTask.new(:all)do|t|t.test_files=FileList['test_*.rb']endFileList['test_*.rb'].eachdo|task|n

  10. ruby - Ruby 脚本如何检测到它正在 irb 中运行？ - 2

    我有一个定义类的Ruby脚本。我希望脚本执行语句BoolParser.generate:file_base=>'bool_parser'仅当脚本作为可执行文件被调用时，而不是当它被irbrequire(或通过-r在命令行上传递)时。我可以用什么来包装上面的语句，以防止它在我的Ruby文件加载时执行？ 最佳答案 条件$0==__FILE__...!/usr/bin/ruby1.8classBoolParserdefself.generate(args)p['BoolParser.generate',args]endendif$0==_

随机推荐