MySQL 8 的复制可观测性

MySQL查看主从复制信息详解 SHOW REPLICA STATUS 语句详解 阅读详情

本文讲解了 MySQL 8 在复制观测性上带来更丰富的观测信息。

作者:Frederic Descamps MySQL 社区经理

本文来源:Oracle MySQL 官网博客

  • 爱可生开源社区出品。

许多经验丰富的 MySQL DBA 都使用过 SHOW REPLICA STATUS 输出中的 Seconds_Behind_Source 来判断(异步)复制的运行状态。

注意:这里使用新的术语 REPLICA。我相信所有人都使用过旧的术语。

然而,MySQL 复制机制已经有很大进步,复制功能团队也做了很多工作,能够为 MySQL 中所有可用的复制模式提供的更丰富观测信息。

例如,我们增加了并行复制,组复制等,但是这些信息都无法从原来的 SHOW REPLICA STATUS 输出中看到。

系统库 Performance_Schema 提供了比 SHOW REPLICA STATUS 更好的监控和观察复制进程的方式。

当前,Performance_Schema 中有 15 张表用于记录复制信息量化:

+------------------------------------------------------+
| Tables_in_performance_schema (replication%)          |
+------------------------------------------------------+
| replication_applier_configuration                    |
| replication_applier_filters                          |
| replication_applier_global_filters                   |
| replication_applier_status                           |
| replication_applier_status_by_coordinator            |
| replication_applier_status_by_worker                 |
| replication_asynchronous_connection_failover         |
| replication_asynchronous_connection_failover_managed |
| replication_connection_configuration                 |
| replication_connection_status                        |
| replication_group_communication_information          |
| replication_group_configuration_version              |
| replication_group_member_actions                     |
| replication_group_member_stats                       |
| replication_group_members                            |
+------------------------------------------------------+
15 rows in set (0.0038 sec)

但不容置疑,理解这些指标的含义并找出对我们 MySQL DBA 真正有意义的信息也不总是那么容易:例如,副本与数据源是否有延迟?

我准备了一些视图,可以安装在 sys schema 中,利用这些指标为我们 DBA 提供相关信息。

我们来更仔细地看一下这些视图。

复制延迟

select * from sys.replication_lag;
+---------------------------+-----------------------+------------------------+
| channel_name              | max_lag_from_original | max_lag_from_immediate |
+---------------------------+-----------------------+------------------------+
| clusterset_replication    | 00:00:04.963223       | 00:00:04.940782        |
| group_replication_applier | 0                     | 0                      |
+---------------------------+-----------------------+------------------------+

从上面的输出中,我们可以看到此实例是一个异步复制的副本,但它也是组复制集群的一部分。

事实上,这是 InnoDB ClusterSet 中 DR 集群的主要成员。

我们还可以看到这个副本的迟到差不多有 5 秒。

然后,我们会看到复制通道的名称,以及与原始提交者和直接源(在级联复制的情况下)的最大延迟(因为在并行复制的情况下可能有多个工作线程)。

在组复制集群(InnoDB Cluster)的 Secondary 节点上,我们可以看到以下输出:

select * from sys.replication_lag;
+----------------------------+-----------------------+------------------------+
| channel_name               | max_lag_from_original | max_lag_from_immediate |
+----------------------------+-----------------------+------------------------+
| group_replication_recovery | null                  | null                   |
| group_replication_applier  | 00:00:02.733008       | 00:00:02.733008        |
+----------------------------+-----------------------+------------------------+

我们可以看到,用于恢复的通道(当节点加入组时读取丢失的二进制日志事件、事务)没有被使用,而组复制的应用程序相对源节点稍有滞后。

复制状态

这个视图更完整,每个工作线程都有一行。

以我们 DR 站点 InnoDB ClusterSet 中的 Primary 节点为例:

select * from replication_status;
+-------------------------------+----------+----------+---------+-------------------+--------------------+
| channel                       | io_state | co_state | w_state | lag_from_original | lag_from_immediate |
+-------------------------------+----------+----------+---------+-------------------+--------------------+
| group_replication_applier (1) | ON       | ON       | ON      | none              | none               |
| group_replication_applier (2) | ON       | ON       | ON      | none              | none               |
| group_replication_applier (3) | ON       | ON       | ON      | none              | none               |
| group_replication_applier (4) | ON       | ON       | ON      | none              | none               |
| clusterset_replication (1)    | ON       | ON       | ON      | 00:00:15.395870   | 00:00:15.380884    |
| clusterset_replication (2)    | ON       | ON       | ON      | 00:00:15.395686   | 00:00:15.380874    |
| clusterset_replication (3)    | ON       | ON       | ON      | 00:00:15.411204   | 00:00:15.388451    |
| clusterset_replication (4)    | ON       | ON       | ON      | 00:00:15.406154   | 00:00:15.388434    |
+-------------------------------+----------+----------+---------+-------------------+--------------------+

可以看到,集群并行(异步)复制使用 4 个并行工作线程。

你可能注意到有 3 种状态(所有都为 ON)。但使用 SHOW REPLICA STATUS 我们只能看到:

       Replica_IO_Running: Yes
      Replica_SQL_Running: Yes

通过并行复制,我们在应用 binlog 事件期间有另一个线程参与复制:coordinator 线程。

完整复制状态信息

当然,我们也可以获取更多关于复制的详细信息。

来看一个结果例子:

select * from sys.replication_status_full\G
*************************** 1. row ***************************
                 channel: group_replication_applier (1)
                    host: <NULL>
                    port: 0
                    user:
             source_uuid: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
              group_name: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
last_heartbeat_timestamp: 0000-00-00 00:00:00.000000
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: NULL
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Replica has read all relay log; waiting for more updates
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: Waiting for an event from Coordinator
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 03:36:40.474223
      applier_busy_state: IDLE
       lag_from_original: none
      lag_from_immediate: none
          transport_time: 1.80 us
       time_to_relay_log: 12.00 us
              apply_time: 784.00 us
last_applied_transaction: 7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e:3
 last_queued_transaction: 7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e:3
queued_gtid_set_to_apply:
*************************** 2. row ***************************
                 channel: group_replication_applier (2)
                    host: <NULL>
                    port: 0
                    user:
             source_uuid: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
              group_name: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
last_heartbeat_timestamp: 0000-00-00 00:00:00.000000
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: NULL
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Replica has read all relay log; waiting for more updates
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: Waiting for an event from Coordinator
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 03:36:40.474223
      applier_busy_state: IDLE
       lag_from_original: none
      lag_from_immediate: none
          transport_time: 1.80 us
       time_to_relay_log: 12.00 us
              apply_time:   0 ps
last_applied_transaction:
 last_queued_transaction: 7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e:3
queued_gtid_set_to_apply:
*************************** 3. row ***************************
                 channel: group_replication_applier (3)
                    host: <NULL>
                    port: 0
                    user:
             source_uuid: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
              group_name: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
last_heartbeat_timestamp: 0000-00-00 00:00:00.000000
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: NULL
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Replica has read all relay log; waiting for more updates
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: Waiting for an event from Coordinator
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 03:36:40.474223
      applier_busy_state: IDLE
       lag_from_original: none
      lag_from_immediate: none
          transport_time: 1.80 us
       time_to_relay_log: 12.00 us
              apply_time:   0 ps
last_applied_transaction:
 last_queued_transaction: 7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e:3
queued_gtid_set_to_apply:
*************************** 4. row ***************************
                 channel: group_replication_applier (4)
                    host: <NULL>
                    port: 0
                    user:
             source_uuid: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
              group_name: 7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e
last_heartbeat_timestamp: 0000-00-00 00:00:00.000000
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: NULL
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Replica has read all relay log; waiting for more updates
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: Waiting for an event from Coordinator
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 03:36:40.474223
      applier_busy_state: IDLE
       lag_from_original: none
      lag_from_immediate: none
          transport_time: 1.80 us
       time_to_relay_log: 12.00 us
              apply_time:   0 ps
last_applied_transaction:
 last_queued_transaction: 7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e:3
queued_gtid_set_to_apply:
*************************** 5. row ***************************
                 channel: clusterset_replication (1)
                    host: 127.0.0.1
                    port: 3310
                    user: mysql_innodb_cs_b0adbc6c
             source_uuid: 2cb77a02-40eb-11ee-83f4-c8cb9e32df8e
              group_name:
last_heartbeat_timestamp: 2023-08-22 18:48:41.037817
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: Waiting for source to send event
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Waiting for replica workers to process their queues
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: waiting for handler commit
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 00:00:00.001134
      applier_busy_state: APPLYING
       lag_from_original: 00:00:01.799071
      lag_from_immediate: 00:00:01.783404
          transport_time: 2.26 ms
       time_to_relay_log: 19.00 us
              apply_time: 14.63 ms
last_applied_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105180
 last_queued_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105547
queued_gtid_set_to_apply: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105184-105547
*************************** 6. row ***************************
                 channel: clusterset_replication (2)
                    host: 127.0.0.1
                    port: 3310
                    user: mysql_innodb_cs_b0adbc6c
             source_uuid: 2cb77a02-40eb-11ee-83f4-c8cb9e32df8e
              group_name:
last_heartbeat_timestamp: 2023-08-22 18:48:41.037817
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: Waiting for source to send event
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Waiting for replica workers to process their queues
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: waiting for handler commit
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 00:00:00.001134
      applier_busy_state: APPLYING
       lag_from_original: 00:00:01.797743
      lag_from_immediate: 00:00:01.783390
          transport_time: 2.26 ms
       time_to_relay_log: 19.00 us
              apply_time: 21.47 ms
last_applied_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105181
 last_queued_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105547
queued_gtid_set_to_apply: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105184-105547
*************************** 7. row ***************************
                 channel: clusterset_replication (3)
                    host: 127.0.0.1
                    port: 3310
                    user: mysql_innodb_cs_b0adbc6c
             source_uuid: 2cb77a02-40eb-11ee-83f4-c8cb9e32df8e
              group_name:
last_heartbeat_timestamp: 2023-08-22 18:48:41.037817
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: Waiting for source to send event
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Waiting for replica workers to process their queues
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: waiting for handler commit
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 00:00:00.001134
      applier_busy_state: APPLYING
       lag_from_original: 00:00:01.786087
      lag_from_immediate: 00:00:01.767563
          transport_time: 2.26 ms
       time_to_relay_log: 19.00 us
              apply_time: 21.58 ms
last_applied_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105182
 last_queued_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105547
queued_gtid_set_to_apply: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105184-105547
*************************** 8. row ***************************
                 channel: clusterset_replication (4)
                    host: 127.0.0.1
                    port: 3310
                    user: mysql_innodb_cs_b0adbc6c
             source_uuid: 2cb77a02-40eb-11ee-83f4-c8cb9e32df8e
              group_name:
last_heartbeat_timestamp: 2023-08-22 18:48:41.037817
      heartbeat_interval: 30
                io_state: ON
         io_thread_state: Waiting for source to send event
                io_errno: 0
               io_errmsg:
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Waiting for replica workers to process their queues
                co_errno: 0
               co_errmsg:
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: waiting for handler commit
                 w_errno: 0
                w_errmsg:
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 00:00:00.001134
      applier_busy_state: APPLYING
       lag_from_original: 00:00:01.785881
      lag_from_immediate: 00:00:01.767550
          transport_time: 2.26 ms
       time_to_relay_log: 19.00 us
              apply_time: 29.59 ms
last_applied_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105183
 last_queued_transaction: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105547
queued_gtid_set_to_apply: 54d83026-40eb-11ee-a5d3-c8cb9e32df8e:105184-105547

通过这个视图,我们可以获得更多详细信息,例如复制心跳。我们还对 GTID(排队、应用等)进行了概述。

我们也可以看到传输时间(网络)、写入中继日志的时间以及最终应用的时间等信息。

当然,您可以根据需要来选择视图的显示内容,例如:

InnoDB 集群,ClusterSet,只读副本

如果使用由 Admin API 和 MySQL Shell 管理的集成解决方案,那么所有这些信息已经通过 status() 方法可以获知。

status() 方法可以扩展 3 个值:

  1. 返回集群元数据版本、组协议版本、组名称、集群成员 UUID、成员角色和状态(由组复制报告),及被隔离的系统变量列表。

  2. 返回每个连接和应用程序处理的事务信息。

  3. 返回每个集群成员复制机制更详细的统计信息。

下面来看一下扩展选项 3 的 ClusterSet 示例:

JS> cs.status({extended:3})
{
    "clusters": {
        "cluster2": {
            "clusterRole": "REPLICA",
            "clusterSetReplication": {
                "applierQueuedTransactionSet": "54d83026-40eb-11ee-a5d3-c8cb9e32df8e:137385-138500",
                "applierQueuedTransactionSetSize": 1116,
                "applierState": "ON",
                "applierStatus": "APPLYING",
                "applierThreadState": "waiting for handler commit",
                "applierWorkerThreads": 4,
                "coordinatorState": "ON",
                "coordinatorThreadState": "Waiting for replica workers to process their queues",
                "options": {
                    "connectRetry": 3,
                    "delay": 0,
                    "heartbeatPeriod": 30,
                    "retryCount": 10
                },
                "receiver": "127.0.0.1:4420",
                "receiverStatus": "ON",
                "receiverThreadState": "Waiting for source to send event",
                "receiverTimeSinceLastMessage": "00:00:00.002737",
                "replicationSsl": null,
                "source": "127.0.0.1:3310"
            },
            "clusterSetReplicationStatus": "OK",
            "communicationStack": "MYSQL",
            "globalStatus": "OK",
            "groupName": "7b6bf13d-40ed-11ee-bfdd-c8cb9e32df8e",
            "groupViewChangeUuid": "7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e",
            "paxosSingleLeader": "OFF",
            "receivedTransactionSet": "54d83026-40eb-11ee-a5d3-c8cb9e32df8e:129-138500",
            "ssl": "REQUIRED",
            "status": "OK_NO_TOLERANCE",
            "statusText": "Cluster is NOT tolerant to any failures.",
            "topology": {
                "127.0.0.1:4420": {
                    "address": "127.0.0.1:4420",
                    "applierWorkerThreads": 4,
                    "fenceSysVars": [
                        "read_only",
                        "super_read_only"
                    ],
                    "memberId": "c3d726ac-40ec-11ee-ab38-c8cb9e32df8e",
                    "memberRole": "PRIMARY",
                    "memberState": "ONLINE",
                    "mode": "R/O",
                    "readReplicas": {},
                    "replicationLagFromImmediateSource": "00:00:05.420247",
                    "replicationLagFromOriginalSource": "00:00:05.433548",
                    "role": "HA",
                    "status": "ONLINE",
                    "version": "8.1.0"
                },
                "127.0.0.1:4430": {
                    "address": "127.0.0.1:4430",
                    "applierWorkerThreads": 4,
                    "fenceSysVars": [
                        "read_only",
                        "super_read_only"
                    ],
                    "memberId": "709b15ea-40ed-11ee-a9b3-c8cb9e32df8e",
                    "memberRole": "SECONDARY",
                    "memberState": "ONLINE",
                    "mode": "R/O",
                    "readReplicas": {},
                    "replicationLagFromImmediateSource": "00:00:00.038075",
                    "replicationLagFromOriginalSource": "00:00:05.432536",
                    "role": "HA",
                    "status": "ONLINE",
                    "version": "8.1.0"
                }
            },
            "transactionSet": "2cb77a02-40eb-11ee-83f4-c8cb9e32df8e:1-4,54d83026-40eb-11ee-a5d3-c8cb9e32df8e:1-137384,54d8329c-40eb-11ee-a5d3-c8cb9e32df8e:1-5,7b6bf4f0-40ed-11ee-bfdd-c8cb9e32df8e:1-3",
            "transactionSetConsistencyStatus": "OK",
            "transactionSetErrantGtidSet": "",
            "transactionSetMissingGtidSet": "54d83026-40eb-11ee-a5d3-c8cb9e32df8e:137385-138552"
        },
        "myCluster": {
            "clusterRole": "PRIMARY",
            "communicationStack": "MYSQL",
            "globalStatus": "OK",
            "groupName": "54d83026-40eb-11ee-a5d3-c8cb9e32df8e",
            "groupViewChangeUuid": "54d8329c-40eb-11ee-a5d3-c8cb9e32df8e",
            "paxosSingleLeader": "OFF",
            "primary": "127.0.0.1:3310",
            "ssl": "REQUIRED",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "applierWorkerThreads": 4,
                    "fenceSysVars": [],
                    "memberId": "2cb77a02-40eb-11ee-83f4-c8cb9e32df8e",
                    "memberRole": "PRIMARY",
                    "memberState": "ONLINE",
                    "mode": "R/W",
                    "readReplicas": {
                        "127.0.0.1:4410": {
                            "address": "127.0.0.1:4410",
                            "applierStatus": "APPLYING",
                            "applierThreadState": "waiting for handler commit",
                            "applierWorkerThreads": 4,
                            "receiverStatus": "ON",
                            "receiverThreadState": "Waiting for source to send event",
                            "replicationSources": [
                                "PRIMARY"
                            ],
                            "replicationSsl": "TLS_AES_256_GCM_SHA384 TLSv1.3",
                            "role": "READ_REPLICA",
                            "status": "ONLINE",
                            "version": "8.1.0"
                        }
                    },
                    "role": "HA",
                    "status": "ONLINE",
                    "version": "8.1.0"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "applierWorkerThreads": 4,
                    "fenceSysVars": [
                        "read_only",
                        "super_read_only"
                    ],
                    "memberId": "327cb102-40eb-11ee-9904-c8cb9e32df8e",
                    "memberRole": "SECONDARY",
                    "memberState": "ONLINE",
                    "mode": "R/O",
                    "readReplicas": {},
                    "replicationLagFromImmediateSource": "00:00:04.536190",
                    "replicationLagFromOriginalSource": "00:00:04.536190",
                    "role": "HA",
                    "status": "ONLINE",
                    "version": "8.1.0"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "applierWorkerThreads": 4,
                    "fenceSysVars": [
                        "read_only",
                        "super_read_only"
                    ],
                    "memberId": "3d141d7e-40eb-11ee-933b-c8cb9e32df8e",
                    "memberRole": "SECONDARY",
                    "memberState": "ONLINE",
                    "mode": "R/O",
                    "readReplicas": {},
                    "replicationLagFromImmediateSource": "00:00:04.652745",
                    "replicationLagFromOriginalSource": "00:00:04.652745",
                    "role": "HA",
                    "status": "ONLINE",
                    "version": "8.1.0"
                }
            },
            "transactionSet": "2cb77a02-40eb-11ee-83f4-c8cb9e32df8e:1-4,54d83026-40eb-11ee-a5d3-c8cb9e32df8e:1-138552,54d8329c-40eb-11ee-a5d3-c8cb9e32df8e:1-5"
        }
    },
    "domainName": "myClusterSet",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "myCluster",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

结论

复制部分的可观察性非常详细,并通过 MySQL 8 提供了大量信息。也许现在是改变查看或监视复制方式的好时机。

更多技术文章,请访问: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
【数据库与中间件 】MySQL 8.3性能调优十大新特性解读与实测 MySQL 8.3性能调优十大新特性深度解析 摘要:MySQL 8.3作为创新版本,带来了多项性能优化特性。核心改进包括:1)带标记的GTID复制提升事务管理效率;2)JSON EXPLAIN格式版本控制保障优化器兼容性;3)增强的线程池插件实现精细化连接管理;4)性能模式扩展提供更详尽的监控数据;5)二进制日志依赖跟踪优化减少复制延迟。实测显示,新版本在OLTP性能、复杂查询响应时间和内存使用效率等方面均有显著提升,其中复制延迟降低28.9%,连接池效率提高8.2%。升级建议包括完整备份、兼容性测试及合理 阅读详情

相关推荐

别再把 MySQL 当 CRUD:MySQL 8.4 LTS 生产实战全景

很多线上数据库事故并不是由某一条“特别慢”的 SQL 单独引起,而是由一条完整的故障链触发:流量突增导致应用线程堆积,连接池被占满,长事务扩大锁范围,慢查询进一步消耗 CPU 与 I/O,复制延迟持续上升,最终演变成订单超时、库存回滚失败、主从切换风险和全链路雪崩。五大核心模块:连接与并发、优化器与索引、InnoDB 内存与 I/O、事务与锁、日志与恢复。七大生产机制:高可用、读写路由、分片、CDC、备份恢复、可观测性、限流与降级。

一起修行,不孤单。这里有编程语言、开发工具、学习方法论和踩坑笔记。用简单的话说复杂的事,陪你从小白到进阶。周更干货,欢迎一起成长! 249

MySQL 8 主从延迟监控(复制可观测性)

作者 | Frederic Descamps来源 |https://dev.mysql.com/blog-archive/mysql-8-and-replication-observability/大家好,我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 MySQL 8 主从延迟监控(复制可观测性),欢迎点击上方蓝字“JiekeXu DBA之路”关注我的公众号,标星或置顶,更多干货...

JiekeXu的博客 1219

从零开始掌握Simscape Multibody:机械系统建模与仿真入门

本文为机械系统建模与仿真入门指南,详细介绍了如何从零开始使用Simscape Multibody。通过构建曲柄摇块机构的实战案例,系统讲解了刚体、关节、约束等核心模块的使用,以及模型验证、参数化设计和多领域系统集成等进阶技巧,帮助工程师和学生高效进行虚拟设计与测试。

weixin_29229261的博客 310

技术分享 | MySQL 突如其来的主从复制延迟

作者:刘开洋 爱可生交付服务团队北京 DBA,对数据库及周边技术有浓厚的学习兴趣,喜欢看书,追求技术。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 前几天来自生产上的一个问题,又涨知识了,今天拿来分享给大家。 现象与分析 现象是监控显示主从出现延迟,那我们就得登上数据库看看究竟出现了什么事? [root@localhost][(none)]> show slave status\G *************************** 1.

ActionTech的博客 799

SAP S/4HANA Public Cloud 配置全景实践

本文提供SAP S/4HANA Public Cloud配置的实用指南,重点介绍三大核心工具:CBC(范围界定与配置)、SAP Activate(方法论与路线图)和Cloud ALM(项目执行与运维)。文章详解了不同系统架构(2SL/3SL)的配置路径,并以制造企业案例说明端到端实施流程。同时提供了工具协同操作方法、初始访问安全建议和常见问题的专家意见,帮助项目团队高效完成实施工作。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 560

YOLOv11改进策略【损失函数篇】| arXiv2025 TeLU双曲正切指数线性单元 强梯度防消失 + 解析光滑稳训练,极速提升收敛与泛化

本文记录的是。TeLU(Hyperbolic Tangent Exponential Linear Unit)通过。本文利用TeLU激活函数,以x⋅tanhex统一实现正区间强梯度加速收敛与负区间持续梯度避免死神经元,全程保持解析光滑与极低计算开销,,显著提升深度网络在分类、检测、分割、时序任务中的收敛速度、精度与泛化鲁棒性。

Limiiiing的博客 224

mysql主从复制出现Waiting for Slave Worker to release partition

原文地址 第一节   并行复制 Mysql5.6的mts(并行复制)是基于database来分发事务的,coordinator(原来的sql thread)按照slave worker与db的对应关系进行处理来分发事务给相应的slave worker,slave worker代替了sql thread来执行事务中的event。并且mysql默认认为数据是以databas

yunqishequ1的博客 1920

【32】OpenCV——图像含义关系?RGGB , BGGR , GRBG , GBRG呢?raw8,raw10,raw12,raw14呢? YUV422; RAW16呢?YCbYCr/RG_GB;

‌如前所述,定义原始数据的位深精度。‌* ‌一种压缩色彩编码方式,通过色度抽样(亮度Y全分辨率,色度U/V半分辨率)减少数据量,常用于视频传输。‌* ‌可能指每个像素分量占16位存储(如高位填充的RAW10/12/14),或未明确量化的高精度原始数据。‌ ‌分类‌核心定义‌关联性及典型应用传感器原始色彩排列(RGGB/BGGR等)决定RAW数据的色彩分布规则RAW位深每个分量的数据精度(8/10/12/14位)影响动态范围和存储空间‌YUV422。

程序员,他们想的是什么?他们想的永远都是技术,他们崇尚的也永远都是技术。 791

-备库有延迟怎么办?

使用MySQL的数据复制功能时,要监控好备库的状态和延迟情况。很多原因都会导致备库延迟,这一讲中提供了一些基本的方法。有一些延迟问题是可以避免的。如果是因为主库写入并发高引起的延迟,使用多线程复制能在一定程度上降低延迟。主库上参数binlog_transaction_dependency_tracking设置为WRITESET,能提升事务在备库的可并行度。如果你使用了级联复制架构,中间层的实例上,也要将 binlog_transaction_dependency_tracking设置为WRITESET。

qq_33240556的博客 973

高通平台开发系列讲解(USB篇)MBIM协议详解

📢本文主要介绍高通平台USB网卡MBIM协议。

内核笔记 5438

【StarRocks】-- DATETIME 与 TIMESTAMP 区别详解

本文详细解析了StarRocks中DATETIME/DATETIMEV2与TIMESTAMP的区别及使用场景。DATETIME系列存储人类可读时间,不携带时区;TIMESTAMP实际指Unix时间戳,建议用BIGINT存储。关键差异包括:精度选择(DATETIMEV2支持微秒级)、时区处理(仅函数计算时影响)、存储方式等。针对不同场景提供选型建议:单时区展示用DATETIMEV2,跨时区计算用BIGINT存储Epoch。特别强调与MySQL迁移时的注意事项,并给出常见问题解决方案和最佳实践清单,包括统一入口

欢迎来到我的博客,一起探索代码里的世界! 497

K8s生产环境MySQL高可用方案:基于Helm的MySQL8.0主从架构配置详解

本文详细介绍了在Kubernetes生产环境中,如何利用Helm部署并优化MySQL 8.0的一主两从高可用架构。通过深度定制Bitnami的MySQL Helm Chart,配置StatefulSet、持久化存储及服务,实现读写分离与数据冗余。文章涵盖从环境准备、部署实战到监控备份、故障转移等生产级运维策略,为构建坚如磐石的云原生数据库服务提供完整指南。

web99的专栏 477

【YOLOv8-pose姿态识别部署至RK3588:模型训练到RKNN落地,让人体姿态分析精度与边缘推理速度双突破】

本教程从YOLOv8-pose模型的姿态识别训练,到RK3588的边缘量化部署,为你打造了一套“高精度+高实时性+低成本”的人体姿态分析解决方案。无论是健身动作纠正、智能安防行为检测,还是工业人员姿态监控,这套技术都能直接复用——你只需替换数据集与业务逻辑,即可快速落地专属的边缘AI姿态识别系统。如果你在实践中遇到任何卡点,欢迎随时交流。记住,人体姿态识别的价值在于“关键点准、推理快、部署易”,而这三者的平衡,正是你通过本教程能掌握的核心能力。

FJN110的博客 329

企业级MySQL8.0高可用安装实战指南

它的工作流程是:应用程序的所有数据库请求都发送给ProxySQL,ProxySQL根据我们预先设定的规则,将写请求(如INSERT, UPDATE, DELETE)转发给主库,将读请求(SELECT)转发给配置好的从库组。Grafana则负责数据的可视化展示,我们可以从官网导入现成的MySQL监控仪表盘模板,几分钟内就能看到丰富的图表,监控QPS、TPS、慢查询、复制延迟等关键指标,一目了然。,开启慢查询日志并设置合适的阈值(如2秒),定期分析优化慢SQL,这往往是性能提升的关键。

ThunderstormLynx23的博客 178

uniapp中使用canvas生成海报,并下载保存到手机相册

如下图,是在H5中,canvas生成后的效果,首先说明,H5不支持返回图片的临时路径,不能用于保存,APP端生成成功后,会返回图片的临时路径用来保存到相册。本地测试,用的网络图片,没有出现跨域的问题,APP端也正常显示。 完整代码:可以将整个代码复制到你得uniapp项目中直接运行。代码中做了详细的注册,关于API的用法,这里只标注的简单的提示,具体还是参考 官方链接uniapp-canvas吧 <template> <view class="demo"> <c.

sunluyi的博客 3万+

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

MySQL 知多少 v1.0

MySQL 8.0技术指南摘要 MySQL是全球最流行的开源关系型数据库,适用于Web应用、OLTP等场景。本文基于MySQL 8.0.x版本,介绍其核心特性与演进历程。8.0版本重大改进包括:UTF8MB4默认字符集、窗口函数、CTE、数据字典重构等。MySQL采用InnoDB引擎,支持ACID事务、MVCC、B+Tree索引等关键技术,但不适合大规模OLAP、海量写入等场景。与PostgreSQL、TiDB等相比,MySQL在Web应用、读写分离等场景更具优势。适合开发者、DBA及架构师学习使用。

小飞的博客 802

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

What to Monitor in MySQL 8.0

Monitoring is a must in all environments, and databases aren’t the exception. Once you have your database infrastructure up-and-running, you’ll need to keep tabs on what’s happening. Monitoring is a must if you want to be sure everything is going fine but

allway2的博客 142

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

DigitalOcean Blueprints实战:Node.js+MySQL主从+Cachet可观测基建

基础设施即代码(IaC)是现代云原生运维的核心范式,其本质是将环境配置、服务部署与状态管理转化为可版本化、可复现、可审计的代码。DigitalOcean Blueprints 正是面向轻量级生产场景的 IaC 封装实践,底层融合 Terraform 与 Ansible,屏蔽复杂脚手架,聚焦最小可行验证。它不提供黑盒一键部署,而是交付结构清晰、变量分层、错误可溯的生产就绪模板。典型组合如 Node.js 服务层、MySQL 异步主从复制、Cachet 状态页,共同构成高可用、可观测、易降级的基础架构闭环。本文

weixin_34348805的博客 347

MySQL 8.0 复制搭建与可观测监控

2020 年美国科技界纷纷响应 Black Lives Matter,BLM 维权运动,将带有种族色彩的词汇替换,MySQL 也将 master、slave 等关键字进行替换,但是没有彻底删除,留给用户过渡的空间。在 2024 年 4 月 30 日 MySQL 发布的 8.4 LTS 版本中带有种族色彩的关键字已经彻底删除。本篇文章将介绍在新版本中搭建备库的语法,还有一些基于新特性搭建和监控复制的有趣的方法。

分享既学习 803

MySQL 可观测性最佳实践

本文介绍如何通过观测云采集和监控 MySQL 指标数据,识别和解决性能瓶颈,预测资源需求,优化数据库配置,以及确保数据的完整性和安全性,从而提高数据库的可靠性和业务连续性。

观测云的博客 1312

【转载】-MySQL+8.0数据库新特性及测试2

目录

langhailove_2008的博客 394

mysql的实时复制教程_ClickHouse和他的朋友们(11)MySQL实时复制之GTID模式

最后更新: 2020-09-03几天前 ClickHouse 官方发布了 v20.8.1.4447-testing ,这个版本已经包含了 MaterializeMySQL 引擎,实现了 ClickHouse 实时复制 MySQL 数据的能力,感兴趣的朋友可以通过官方安装包来做体验,安装方式参考: https://clickhouse.tech/#quick-start ,需要注意的是要选择 te...

weixin_32532029的博客 120

MySQL 5.4 → 5.5 → 5.6 → 5.7 → 8.0 → 8.4 LTS 的主要版本演进差异对比

角色/需求建议版本理由老旧系统迁移先至 5.7 再升级 8.0/8.4跨版本跨度大,风险高企业稳定性优先LTS 长期支持,兼容性好需要 JSON/窗口函数/CTE至少 8.05.7 不支持上述现代 SQL 特性运维诊断/性能分析为核心8.0 起sysschema 更完善高并发/高可用场景8.0 起原生 Group Replication、多线程复制如你有“某版本升级到某版本的具体操作步骤”、“升级兼容性检查”、“MySQL 8.4 的生产部署指南”等需求,我可以继续细化提供。

喝醉酒的小白 5516

成大事数据库技术面试题系列17:MySQL主从复制与高可用面试题 | 第6-10题 | 从GTID到监控运维,深入掌握复制技术

MySQL主从复制与高可用面试题解析(6-10题) 摘要:本文深入解析MySQL主从复制与高可用架构中的5个核心面试题,重点覆盖GTID复制、读写分离、双主复制、半同步复制和监控运维等关键技术要点。GTID复制通过全局事务ID实现自动定位和故障恢复,读写分离可通过应用层、中间件和MySQL Router实现,双主复制需注意数据冲突问题,半同步复制保障数据安全性与性能平衡,而全面的监控体系(SHOW SLAVE STATUS、Prometheus等)是运维的关键。这些技术共同构成了MySQL高可用架构的核心要

成大事的博客 555

Zabbix 7 最新版本安装 Rocky Linux 8

Rocky Linux 9 安装新版本ZABBIX 7 监控

五指山的网络员 2529

Helm部署Laravel+MySQL生产实践:从配置管理到可观测性

Helm 是 Kubernetes 生态中面向应用交付的包管理工具,其核心价值在于将复杂的 YAML 编排抽象为可复用、可版本化、可审计的应用包(Chart)。相比 Kustomize 等配置补丁方案,Helm 通过 values.yaml 分层、模板函数和依赖管理,天然支持多环境交付与跨集群一致性治理。在 PHP 应用场景下,Laravel 的配置注入、生命周期钩子(如 artisan migrate)与 MySQL 的有状态拓扑(StatefulSet/PVC/主从)需深度协同——这正是 Helm 模板

weixin_34068198的博客 362
上一篇: 主从数据不一致竟然不报错?
下一篇: MySQL 如何避免 RC 隔离级别下的 INSERT 死锁?
爱可生开源社区
博客等级 码龄8年 1936粉丝 1004原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值