不知不觉中,performance_schema系列快要接近尾声了,今天将带领大家一起踏上系列第六篇的征程(全系共7个篇章),在这一期里,我们将为大家全面讲解performance_schema中的复制状态与变量统计表。下面,请跟随我们一起开始performance_schema系统的学习之旅吧~
通常,DBA或相关数据库运维人员在查看从库的复制相关的信息,都习惯性的使用show slave status语句查看。也许你会说,我也会用performance_schema下的表查看一些复制报错信息什么的。但是,你知道show slave status语句、mysql系统库下的复制信息记录表、performance_schema系统库下的复制信息记录表之间有什么区别吗?不知道?别急,本文即将为你详细介绍show slave status语句与performance_schema系统库下的复制信息记录表的区别(mysql系统库下的复制表区别详见后续 "mysql系统库全方位介绍"系列)。
在开始详细介绍每一张复制信息表之前,我们先花费一些篇幅来整体认识一下这些表。
performance_schema 系统库下提供了如下几个与复制状态相关的表(表含义详见本文后续小节):
这些复制表中记录的信息生命周期如下(生命周期即指的是这些表中的信息什么时候写入,什么时候会被修改,什么时候会被清理等):
performance_schema 系统库中保存的复制信息与SHOW SLAVE STATUS输出的信息有所不同(performance_schema 中记录的一些复制信息是show slave status语句输出信息中没有的,但是也仍然有一些show slave status语句输出的复制信息是performance_schema 中没有的),因为这些表面向全局事务标识符(GTID)使用,而不是基于binlog pos位置,所以这些表记录server UUID值,而不是server ID值。show slave status语句输出的信息在performance_schema 中缺少的内容如下:
用于引用binlog file、pos和relay log file、pos等信息选项,在performance_schema表中不记录 。
PS1:如下系统状态变量被移动到了这些复制状态表中进行记录(MySQL 5.7.5版之前使用以下状态变量查看):
PS2:对于组复制架构,组复制的监控信息散布在如下几张表中
通过以上内容,我们从整体上能够大致了解了performance_schema中的复制信息表记录了什么信息,下面依次详细介绍这些复制信息表。
该表中记录从库线程延迟复制的配置参数(延迟复制的线程被称为普通线程,比如CHANNEL_NAME和DESIRED_DELAY字段记录某个复制通道是否需要执行延迟复制,如果是MGR集群,则记录组复制从节点的延迟复制配置参数),该表中的记录在Server运行时可以使用CHANGE MASTER TO语句进行更改,我们先来看看表中记录的统计信息是什么样子的。
# 如果是单主或多主复制,则该表中会为每个复制通道记录一条类似如下信息
admin@localhost : performance_schema 02:49:12> select * from replication_applier_configuration;
+--------------+---------------+
| CHANNEL_NAME | DESIRED_DELAY |
+--------------+---------------+
| | 0 |
+--------------+---------------+
1 row in set (0.00 sec)
# 如果是MGR集群,则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 10:56:49> select * from replication_applier_configuration;
+----------------------------+---------------+
| CHANNEL_NAME | DESIRED_DELAY |
+----------------------------+---------------+
| group_replication_applier | 0 |
| group_replication_recovery | 0 |
+----------------------------+---------------+
2 rows in set (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下:
对于replication_applier_configuration表,不允许执行TRUNCATE TABLE语句。
该表中记录的是从库当前的一般事务执行状态(该表也记录组复制架构中的复制状态信息)
我们先来看看表中记录的统计信息是什么样子的。
# 单线程复制和多线程复制时表中的记录相同,如果是多主复制,则每个复制通道记录一行信息
admin@localhost : performance_schema 02:49:28> select * from replication_applier_status;
+--------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME | SERVICE_STATE | REMAINING_DELAY | COUNT_TRANSACTIONS_RETRIES |
+--------------+---------------+-----------------+----------------------------+
| | ON | NULL | 0 |
+--------------+---------------+-----------------+----------------------------+
1 row in set (0.00 sec)
# 如果是MGR集群,则该表会记录如下MGR集群信息
root@localhost : performance_schema 10:58:33> select * from replication_applier_status;
+----------------------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME | SERVICE_STATE | REMAINING_DELAY | COUNT_TRANSACTIONS_RETRIES |
+----------------------------+---------------+-----------------+----------------------------+
| group_replication_applier | ON | NULL | 0 |
| group_replication_recovery | OFF | NULL | 0 |
+----------------------------+---------------+-----------------+----------------------------+
2 rows in set (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下:
对于replication_applier_status表,不允许执行TRUNCATE TABLE语句。
该表中记录的是从库使用多线程复制时,从库的协调器工作状态记录,当从库使用多线程复制时,每个通道下将创建一个协调器和多个工作线程,使用协调器线程来管理这些工作线程。如果从库使用单线程,则此表为空(对应的记录转移到replication_applier_status_by_worker表中记录),我们先来看看表中记录的统计信息是什么样子的。
# 单线程主从复制时,该表为空,为多线程主从复制时表中记录协调者线程状态信息,多主复制时每个复制通过记录一行信息
admin@localhost : performance_schema 02:49:50> select * from replication_applier_status_by_coordinator;
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | THREAD_ID | SERVICE_STATE | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
| | 43 | ON | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
1 row in set (0.00 sec)
# 如果是MGR集群,则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 11:00:11> select * from replication_applier_status_by_coordinator;
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | THREAD_ID | SERVICE_STATE | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
| group_replication_applier | 91 | ON | 0 | | 0000-00-00 00:00:00 |
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
1 row in set (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下:
对于replication_applier_status_by_coordinator表,不允许执行TRUNCATE TABLE语句。
如果从库是单线程,则该表记录一条WORKER_ID=0的SQL线程的状态。如果从库是多线程,则该表记录系统参数slave_parallel_workers指定个数的工作线程状态(WORKER_ID从1开始编号),此时协调器/SQL线程状态记录在replication_applier_status_by_coordinator表,每一个通道都有自己独立的工作线程和协调器线程(每个通道的工作线程个数由slave_parallel_workers参数变量指定,如果是MGR集群时,则该表中记录的工作线程记录为slave_parallel_workers个group_replication_applier线程+1个group_replication_recovery线程),我们先来看看表中记录的统计信息是什么样子的。
# 单线程主从复制时表中记录的内容如下
root@localhost : performance_schema 12:46:10> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| | 0 | 82 | ON | | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
1 row in set (0.00 sec)
# 多线程主从复制时表中的记录内容如下(如果是多主复制,则每个复制通道记录slave_parallel_workers参数指定个数的worker线程信息)
admin@localhost : performance_schema 02:50:18> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| | 1 | 44 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 2 | 45 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 3 | 46 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 4 | 47 | ON | | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
4 rows in set (0.00 sec)
# 如果是MGR集群,则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 11:00:16> select * from replication_applier_status_by_worker;
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| group_replication_recovery | 0 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| group_replication_applier | 1 | 92 | ON | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:104099082 | 0 | | 0000-00-00 00:00:00 |
| group_replication_applier | 2 | 93 | ON | | 0 | | 0000-00-00 00:00:00 |
......
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
17 rows in set (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下:
对于replication_applier_status_by_worker表,不允许执行TRUNCATE TABLE语句。
该表中记录从库用于连接到主库的配置参数,该表中存储的配置信息在执行change master语句时会被修改
我们先来看看表中记录的统计信息是什么样子的。
# 单线程、多线程主从复制时表中记录的内容相同,如果是多主复制,则每个复制通道各自有一行记录信息
admin@localhost : performance_schema 02:51:00> select * from replication_connection_configuration\G;
*************************** 1. row ***************************
CHANNEL_NAME:
HOST: 10.10.20.14
PORT: 3306
USER: qfsys
NETWORK_INTERFACE:
AUTO_POSITION: 1
SSL_ALLOWED: NO
SSL_CA_FILE:
SSL_CA_PATH:
SSL_CERTIFICATE:
SSL_CIPHER:
SSL_KEY:
SSL_VERIFY_SERVER_CERTIFICATE: NO
SSL_CRL_FILE:
SSL_CRL_PATH:
CONNECTION_RETRY_INTERVAL: 60
CONNECTION_RETRY_COUNT: 86400
HEARTBEAT_INTERVAL: 5.000
TLS_VERSION:
1 row in set (0.00 sec)
# 如果是MGR集群,则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 11:02:03> select * from replication_connection_configuration\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
HOST: <NULL>
......
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_recovery
HOST: <NULL>
......
2 rows in set (0.00 sec)
表中各字段含义以及与change master to语句的选项对应关系如下:
注意:对于replication_connection_configuration表,不允许执行TRUNCATE TABLE语句。
该表中记录的是从库IO线程的连接状态信息(也记录组复制架构中其他节点的连接信息,组复制架构中一个节点加入集群之前的数据需要使用异步复制通道进行数据同步,组复制的异步复制通道信息在show slave status中不可见),我们先来看看表中记录的统计信息是什么样子的。
# 多线程和单线程主从复制时表中记录相同,如果是多主复制,则每个复制通道在表中个记录一行信息
root@localhost : performance_schema 12:55:26> select * from replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME:
GROUP_NAME:
SOURCE_UUID: ec123678-5e26-11e7-9d38-000c295e08a0
THREAD_ID: 101
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 136
LAST_HEARTBEAT_TIMESTAMP: 2018-06-12 00:55:22
RECEIVED_TRANSACTION_SET:
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)
# 如果是MGR集群,则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 10:56:40> select * from replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
GROUP_NAME: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
THREAD_ID: NULL
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:104099082
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_recovery
......
2 rows in set (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下:
对于replication_connection_status表,不允许执行TRUNCATE TABLE语句。
该表中记录了MySQL组复制成员的统计信息。仅在组复制组件运行时表中才会有记录,我们先来看看表中记录的统计信息是什么样子的。
root@localhost : performance_schema 11:02:10> select * from replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15287289928409067:1
MEMBER_ID: 5d78a458-30d2-11e8-a66f-5254002a54f2
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 0a1e8349-2e87-11e8-8c9f-525400bdd1f2:1-148826,
2d623f55-2111-11e8-9cc3-0025905b06da:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-104099082
LAST_CONFLICT_FREE_TRANSACTION:
1 row in set (0.00 sec)
表中各字段含义如下:
对于replication_group_member_stats表,不允许执行TRUNCATE TABLE语句。
该表记录组复制架构中,组成员的网络和状态信息。仅在组复制组件运行时表中才会有记录,我们先来看看表中记录的统计信息是什么样子的。
root@localhost : performance_schema 11:03:38> select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 5d78a458-30d2-11e8-a66f-5254002a54f2 | node1 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
1 row in set (0.00 sec)
表中各字段含义如下:
对于replication_group_members表,不允许执行TRUNCATE TABLE语句。
performance_schema提供了一个保存用户定义变量的user_variables_by_thread表(该表也保存由mysql内部连接线程创建的变量)。这些变量是在特定会话中定义的变量,变量名由@字符开头。
我们先来看看表中记录的统计信息是什么样子的。
admin@localhost : performance_schema 01:50:16> select * from user_variables_by_thread;
+-----------+-------------------------+--------------------------------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-------------------------+--------------------------------------+
| 45 | slave_uuid | 4b0027eb-6223-11e7-94ad-525400950aac |
| 45 | master_heartbeat_period | 5000000000 |
| 45 | master_binlog_checksum | CRC32 |
+-----------+-------------------------+--------------------------------------+
3 rows in set (0.01 sec)
表中各字段含义如下:
user_variables_by_thread表不允许使用TRUNCATE TABLE语句
MySQL server维护着许多系统变量,在performance_schema中提供了对全局、当前会话、以及按照线程分组的系统变量信息记录表:
我们先来看看表中记录的统计信息是什么样子的。
# global_variables表
admin@localhost : performance_schema 09:50:31> select * from global_variables limit 5;
+--------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+--------------------------+----------------+
| auto_increment_increment | 2 |
| auto_increment_offset | 2 |
......
5 rows in set (0.01 sec)
# session_variables表(查询结果与global_variables 表类似)
admin@localhost : performance_schema 09:50:40> select * from session_variables limit 5;
.............
# variables_by_thread表
admin@localhost : performance_schema 09:50:52> select * from variables_by_thread limit 5; # 可以看到比前面两张表多了个THREAD_ID 字段来记录线程ID
+-----------+-----------------------------------------+----------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-----------------------------------------+----------------+
| 45 | auto_increment_increment | 2 |
| 45 | auto_increment_offset | 2 |
......
5 rows in set (0.00 sec)
global_variables和session_variables表字段含义如下:
variables_by_thread表字段含义如下:
performance_schema记录系统变量的这些表不支持TRUNCATE TABLE语句
PS:
MySQL server维护着许多状态变量,提供有关其内部相关操作的信息。如下一些performance_schema表中记录着状态变量信息:
我们先来看看表中记录的统计信息是什么样子的。
# global_status表
admin@localhost : performance_schema 11:01:51> select * from global_status limit 5;
+----------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+----------------------------+----------------+
| Aborted_clients | 0 |
| Aborted_connects | 0 |
......
5 rows in set (0.00 sec)
# session_status表(记录内容与global_status 表类似)
admin@localhost : performance_schema 11:02:21> select * from session_status limit 5;
............
# status_by_thread 表
admin@localhost : performance_schema 11:02:49> select * from status_by_thread limit 5;
+-----------+-------------------------+----------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-------------------------+----------------+
| 45 | Bytes_received | 0 |
| 45 | Bytes_sent | 2901 |
......
5 rows in set (0.00 sec)
global_status和session_status表字段含义如下:
status_by_thread表包含每个活跃线程的状态。字段含义如下:
performance_schema允许对这些状态变量信息统计表执行TRUNCATE TABLE语句:
FLUSH STATUS语句会把所有活跃会话的状态变量值聚合到全局状态变量值中,然后重置所有活跃会话的状态变量值,并在account,host和user状态变量对应的统计表中重置已断开连接的状态变量聚合值。
PS:
按照帐号、主机名、用户名为分组对状态变量进行分类数据,例如:按照帐号表统计的表分组列为host和user列,聚合列当然就是状态变量本身(该功能是MySQL 5.7版本新增的),有如下几张表:
我们先来看看表中记录的统计信息是什么样子的。
# status_by_account表
admin@localhost : performance_schema 04:08:36> select * from status_by_account where USER is not null limit 5;
+-------+-----------+-------------------------+----------------+
| USER | HOST | VARIABLE_NAME | VARIABLE_VALUE |
+-------+-----------+-------------------------+----------------+
| admin | localhost | Bytes_received | 6049 |
| admin | localhost | Bytes_sent | 305705 |
.......
5 rows in set (0.00 sec)
# status_by_host表
admin@localhost : performance_schema 04:08:43> select * from status_by_host where HOST is not null limit 5;
+-----------+-------------------------+----------------+
| HOST | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-------------------------+----------------+
| localhost | Bytes_received | 6113 |
| localhost | Bytes_sent | 306310 |
......
5 rows in set (0.00 sec)
# status_by_user表
admin@localhost : performance_schema 04:08:58> select * from status_by_user where USER is not null limit 5;
+-------+-------------------------+----------------+
| USER | VARIABLE_NAME | VARIABLE_VALUE |
+-------+-------------------------+----------------+
| admin | Bytes_received | 6177 |
| admin | Bytes_sent | 306781 |
......
5 rows in set (0.00 sec)
表中各字段含义
状态变量摘要表允许执行TRUNCATE TABLE语句,执行truncate语句时活动会话的状态变量不受影响:
FLUSH STATUS将会话状态从所有活动会话添加到全局状态变量,然后重置所有活动会话的状态变量值,并在按照account、host、user分类聚合表中重置已断开连接的状态变量值。
PS:
host_cache表保存连接到server的主机相关信息缓存,其中包含客户机主机名和IP地址信息,可以用于避免DNS查找。该表可以使用SELECT语句进行查询,但需要在server启动之前开启performance_schema参数,否则表记录为空。
我们先来看看表中记录的统计信息是什么样子的。
root@localhost : performance_schema 10:35:47> select * from host_cache\G;
*************************** 1. row ***************************
IP: 192.168.2.122
HOST: NULL
HOST_VALIDATED: YES
SUM_CONNECT_ERRORS: 0
COUNT_HOST_BLOCKED_ERRORS: 0
COUNT_NAMEINFO_TRANSIENT_ERRORS: 0
COUNT_NAMEINFO_PERMANENT_ERRORS: 1
COUNT_FORMAT_ERRORS: 0
COUNT_ADDRINFO_TRANSIENT_ERRORS: 0
COUNT_ADDRINFO_PERMANENT_ERRORS: 0
COUNT_FCRDNS_ERRORS: 0
COUNT_HOST_ACL_ERRORS: 0
COUNT_NO_AUTH_PLUGIN_ERRORS: 0
COUNT_AUTH_PLUGIN_ERRORS: 0
COUNT_HANDSHAKE_ERRORS: 0
COUNT_PROXY_USER_ERRORS: 0
COUNT_PROXY_USER_ACL_ERRORS: 0
COUNT_AUTHENTICATION_ERRORS: 0
COUNT_SSL_ERRORS: 0
COUNT_MAX_USER_CONNECTIONS_ERRORS: 0
COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0
COUNT_DEFAULT_DATABASE_ERRORS: 0
COUNT_INIT_CONNECT_ERRORS: 0
COUNT_LOCAL_ERRORS: 0
COUNT_UNKNOWN_ERRORS: 0
FIRST_SEEN: 2017-12-30 22:34:51
LAST_SEEN: 2017-12-30 22:35:29
FIRST_ERROR_SEEN: 2017-12-30 22:34:51
LAST_ERROR_SEEN: 2017-12-30 22:34:51
1 row in set (0.00 sec)
表中各字段含义如下:
FLUSH HOSTS和TRUNCATE TABLE host_cache具有相同的效果:它们清除主机缓存。host_cache表被清空并解除阻塞任何因为错误记录数量超过限制而被阻塞的主机连接。FLUSH HOSTS需要RELOAD权限。 TRUNCATE TABLE需要host_cache表的DROP权限。
PS:如果启动选项 skip_name_resolve 设置为ON,则该表不记录任何信息,因为该表的作用就是用于避免、加速域名解析用于,跳过域名解析功能时则该表记录的信息用途不大。
罗小波·沃趣科技高级数据库技术专家
IT从业多年,历任运维工程师,高级运维工程师,运维经理,数据库工程师,曾参与版本发布系统,轻量级监控系统,运维管理平台,数据库管理平台的设计与编写,熟悉MySQL的体系结构时,InnoDB存储引擎,喜好专研开源技术,追求完美。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。