AI 助理
备案控制台
开发者社区 数据库 文章 正文

Mysql：从一个USE DB堵塞故障展开的探讨

2017-11-09 1030
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS PostgreSQL，集群系列 2核4GB
简介：

原创水平有限如有误请指出谢谢！

一、故障描述

今天一个朋友遇到数据库遇到一个严重的故障，故障环境如下：

  • MYSQL 5.6.16
  • RR隔离级别
  • GITD关闭

表现如下：

  • use db不能进入数据库
  • show table status不能查询到表信息
  • schema.processlist来看有大量的 Waiting for table metadata lock

情急之下他杀掉了一大堆线程后发现还是不能恢复，最后杀掉了一个没有及时提交的事物才恢复正常。也仅仅留下了如下图的一个截图：


image.png

二、故障信息提取

还是回到上图，我们可以归纳一下语句类型如下：

  • 1、CREATE TABLE A AS SELECT B
    其STATE为sending data
  • 2、DROP TABLE A
    其STATE为Waiting for table metadata lock
  • 3、SELECT * FROM A
    其STATE为Waiting for table metadata lock
  • 4、 SHOW TABLE STATUS[like 'A']
    其STATE为Waiting for table metadata lock

三、信息分析

要分析出这个案列其实不太容易因为他是MYSQL层MDL LOCK和RR模式innodb row lock的一个综合案列，并且我们要对schema.processlist的STATE比较敏感才行。
建议先阅读我的如下文章来学习MDL LOCK：
http://blog.itpub.net/7728585/viewspace-2143093/

本节关于MDL LOCK的验证使用下面两种方式：

  • 方式1 笔者在MDL LOCK源码加锁函数处加日志输出，如果要分析各种语句加MDL LOCK的类型还只能用这种方式，因为MDL LOCK加锁往往一闪而过，performance_schema.metadata_locks 没有办法观察到。

  • 方式2 处于堵塞情况下使用5.7版本的performance_schema.metadata_locks观察。
    打开如下：

 UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation';
 UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl';
 select * from performance_schema.metadata_locks\G
1、关于CREATE TABLE A AS SELECT B 对B表sending data的分析

关于sending data这个状态其实可以代表很多含义，从我现有的对的了解，这是MYSQL上层对SELECT类型语句的这类语句在INNODB层和MYSQL层进行数据交互的时候一个统称，所以出现它的可能包含:

  • 确实需要访问数据量特别大，可能需要优化。
  • 由于INNODB 层的获取row lock需要等待，比如我们常见的SELECT FOR UPDATE。

同时我们还需要注意在RR模式下SELECT B这一部分加锁方式和INSERT...SELECT是一致的参考不再赘述：
http://blog.itpub.net/7728585/viewspace-2146183/
从他反应的情况因为他在最后杀掉了一个长期的未提交的事物所以他因为是情况2。并且整个CREATE TABLE A AS SELECT B语句由于B表上某些数据库被上了锁而不能获取，导致整个语句处于sending data状态下。

2、关于SHOW TABLE STATUS[like 'A'] Waiting for table metadata lock的分析

这是本案例中最重要的一环，SHOW TABLE STATUS[like 'A']居然被堵塞其STATE为Waiting for table metadata lock并且注意这里是table因为MDL LOCK类型分为很多。我在MDL介绍的那篇文章中提到了desc 一个表的时候会上MDL_SHARED_HIGH_PRIO(SH)，其实在SHOW TABLE STATUS的时候也会对本表上MDL_SHARED_HIGH_PRIO(SH)。

  • 方式1：
mysql> SHOW TABLE STATUS like 'a' \G

2017-11-10T03:01:48.142334Z 6 [Note] (acquire_lock)**THIS MDL LOCK acquire WAIT(MDL_LOCK WAIT QUE)!**
2017-11-10T03:01:48.142381Z 6 [Note] (>MDL PRINT) Thread id is 6: 
2017-11-10T03:01:48.142396Z 6 [Note] (->MDL PRINT) DB_name is:test 
2017-11-10T03:01:48.142409Z 6 [Note] (-->MDL PRINT) OBJ_name is:a 
2017-11-10T03:01:48.142421Z 6 [Note] (--->MDL PRINT) Namespace is:TABLE 
2017-11-10T03:01:48.142434Z 6 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_HIGH_PRIO(SH) 
2017-11-10T03:01:48.142447Z 6 [Note] (------>MDL PRINT) Mdl  duration is:MDL_TRANSACTION
  • 方式2：
*************************** 7. row ***************************
         OBJECT_TYPE: TABLE
       OBJECT_SCHEMA: test
         OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733864665152
           LOCK_TYPE: SHARED_HIGH_PRIO
       LOCK_DURATION: TRANSACTION
         LOCK_STATUS: PENDING
              SOURCE: sql_base.cc:2821
     OWNER_THREAD_ID: 38
      OWNER_EVENT_ID: 1695

两种方式都能观察到MDL_SHARED_HIGH_PRIO(SH)的存在并且我模拟的是处于堵塞情况下的。
但是MDL_SHARED_HIGH_PRIO(SH) 是一个优先级非常高的一个MDL LOCK类型表现如下：

  • 兼容性：
   Request  |  Granted requests for lock                  |
    type    | S  SH  SR  SW  SWLP  SU  SRO  SNW  SNRW  X  |
  ----------+---------------------------------------------+
  SH        | +   +   +   +    +    +   +    +    +    -  |
  • 阻塞队列优先级：
    Request   |  Pending requests for lock      |
      type    | S  SH  SR  SW  SU  SNW  SNRW  X |
    ----------+---------------------------------+
    SH        | +   +   +   +   +   +     +   + |

其被堵塞的条件除了被MDL_EXCLUSIVE(X)堵塞没有其他的可能。那么这就是一个非常重要的突破口。

3、关于CREATE TABLE A AS SELECT B 对A表的加MDL LOCK的分析

这一点也是我以前不知道的,也是本案列中花时间最多的地方,前文已经分析过要让SHOW TABLE STATUS[like 'A']这种只会上MDL_SHARED_HIGH_PRIO(SH) MDL LOCK的语句堵塞在MDL LOCK上只有一种可能那就是A表上了MDL_EXCLUSIVE(X)。那么我开始
怀疑这个DDL语句在语句结束之前会对A表上MDL_EXCLUSIVE(X) ，然后进行实际测试不出所料确实是这样的如下：

  • 方式1：
2017-11-10T05:38:16.824713Z 4 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-11-10T05:38:16.824727Z 4 [Note] (>MDL PRINT) Thread id is 4: 
2017-11-10T05:38:16.824739Z 4 [Note] (->MDL PRINT) DB_name is:test 
2017-11-10T05:38:16.824752Z 4 [Note] (-->MDL PRINT) OBJ_name is:a 
2017-11-10T05:38:16.824764Z 4 [Note] (--->MDL PRINT) Namespace is:TABLE 
2017-11-10T05:38:16.824776Z 4 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-11-10T05:38:16.824788Z 4 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED(S) 
2017-11-10T05:38:16.824799Z 4 [Note] (------>MDL PRINT) Mdl  duration is:MDL_TRANSACTION 
2017-11-10T05:38:16.825286Z 4 [Note] (upgrade_shared_lock)THIS MDL LOCK  upgrade TO
2017-11-10T05:38:16.825312Z 4 [Note] (>MDL PRINT) Thread id is 4: 
2017-11-10T05:38:16.825332Z 4 [Note] (->MDL PRINT) DB_name is:test 
2017-11-10T05:38:16.825345Z 4 [Note] (-->MDL PRINT) OBJ_name is:a 
2017-11-10T05:38:16.825357Z 4 [Note] (--->MDL PRINT) Namespace is:TABLE 
2017-11-10T05:38:16.825369Z 4 [Note] (----->MDL PRINT) Mdl type is:MDL_EXCLUSIVE(X) 
2017-11-10T05:38:16.825381Z 4 [Note] (------>MDL PRINT) Mdl  duration is:MDL_TRANSACTION
  • 方式2：
*************************** 1. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733998842016
            LOCK_TYPE: SHARED
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: GRANTED
               SOURCE: sql_parse.cc:6314
      OWNER_THREAD_ID: 36
       OWNER_EVENT_ID: 1553

这里比较遗憾在performance_schema.metadata_locks中并没有显示出MDL_EXCLUSIVE(X)，而显示为MDL_SHARED(S) 但是我们在我输出的日志中可以看到这里做了升级操作将MDL_SHARED(S) 升级为了MDL_EXCLUSIVE(X)。并且由前面的兼容性列表来看，只有MDL_EXCLUSIVE(X)会堵塞MDL_SHARED_HIGH_PRIO(SH)。所以我们应该能够确认这里确实做了升级操作，否则SHOW TABLE STATUS[like 'A'] 是不会被堵塞的。

4、关于SELECT * FROM A Waiting for table metadata lock的分析

也许大家认为SELECT不会上锁，但是那是在innodb 层次，在MYSQL层会上MDL_SHARED_READ(SR) 如下：

  • 方式1：
 select * from a;

2017-11-10T03:31:31.209772Z 6 [Note] (acquire_lock)THIS MDL LOCK acquire WAIT(MDL_LOCK WAIT QUE)!
2017-11-10T03:31:31.209824Z 6 [Note] (>MDL PRINT) Thread id is 6: 
2017-11-10T03:31:31.209851Z 6 [Note] (->MDL PRINT) DB_name is:test 
2017-11-10T03:31:31.209870Z 6 [Note] (-->MDL PRINT) OBJ_name is:a 
2017-11-10T03:31:31.209885Z 6 [Note] (--->MDL PRINT) Namespace is:TABLE 
2017-11-10T03:31:31.209965Z 6 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_READ(SR) 
2017-11-10T03:31:31.209985Z 6 [Note] (------>MDL PRINT) Mdl  duration is:MDL_TRANSACTION
  • 方式2：
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733864625136
            LOCK_TYPE: SHARED_READ
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: PENDING
               SOURCE: sql_parse.cc:6314
      OWNER_THREAD_ID: 38
       OWNER_EVENT_ID: 1764

可以看到确实有MDL_SHARED_READ(SR)的存在，当前处于堵塞状态

其兼容性如下：

       Request  |  Granted requests for lock                  |
        type    | S  SH  SR  SW  SWLP  SU  SRO  SNW  SNRW  X  |
      ----------+---------------------------------------------+
      SR        | +   +   +   +    +   +    +    +    -    -  |

显然MDL_SHARED_READ(SR) 和MDL_EXCLUSIVE(X)是不兼容的需要等待。

5、关于DROP TABLE A Waiting for table metadata lock的分析

这一点很好分析因为A表上了X锁而DROP TABLE A必然上MDL_EXCLUSIVE(X)锁它当然和MDL_EXCLUSIVE(X)不兼容。如下：

  • 方式1：
 drop table a;

2017-11-09T10:58:28.673015Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-11-09T10:58:28.673030Z 3 [Note] (>MDL PRINT) Thread id is 3: 
2017-11-09T10:58:28.673042Z 3 [Note] (->MDL PRINT) DB_name is:test 
2017-11-09T10:58:28.673054Z 3 [Note] (-->MDL PRINT) OBJ_name is:t10 
2017-11-09T10:58:28.673067Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE 
2017-11-09T10:58:28.673094Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_EXCLUSIVE(X) 
2017-11-09T10:58:28.673109Z 3 [Note] (------>MDL PRINT) Mdl  duration is:MDL_TRANSACTION
  • 方式2：
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733864625472
            LOCK_TYPE: EXCLUSIVE
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: PENDING
               SOURCE: sql_parse.cc:6314
      OWNER_THREAD_ID: 38
       OWNER_EVENT_ID: 1832

其中EXCLUSIVE就是我们说的MDL_EXCLUSIVE(X)它确实存在当前处于堵塞

6、为何use db也会堵塞？

如果使用mysql客户端不使用-A选项(或者 no-auto-rehash)在USE DB的时候至少要做如下事情：

1、 对db下每个表上MDL (SH) lock如下（调用MDL_context::acquire_lock 这里给出堵塞时候的信息）：
  • 方式1：
use test

2017-11-10T03:46:50.223628Z 5 [Note] (acquire_lock)THIS MDL LOCK acquire WAIT(MDL_LOCK WAIT QUE)!
2017-11-10T03:46:50.223666Z 5 [Note] (>MDL PRINT) Thread id is 5: 
2017-11-10T03:46:50.223696Z 5 [Note] (->MDL PRINT) DB_name is:test 
2017-11-10T03:46:50.223714Z 5 [Note] (-->MDL PRINT) OBJ_name is:a 
2017-11-10T03:46:50.223725Z 5 [Note] (--->MDL PRINT) Namespace is:TABLE 
2017-11-10T03:46:50.223735Z 5 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_HIGH_PRIO(SH) 
2017-11-10T03:46:50.223755Z 5 [Note] (------>MDL PRINT) Mdl  duration is:MDL_TRANSACTION
  • 方式2：
*************************** 7. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733797429008
            LOCK_TYPE: SHARED_HIGH_PRIO
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: PENDING
               SOURCE: sql_base.cc:2821
      OWNER_THREAD_ID: 37
       OWNER_EVENT_ID: 187

可以看到USE DB确实也因为MDL_SHARED_HIGH_PRIO(SH) 发生了堵塞。

2、对每个表加入到table cache，并且打开表(调用open_table_from_share())

那么这种情况就和SHOW TABLE STATUS[like 'A']被堵塞的情况一模一样了，也是由于MDL 锁不兼容造成的。

四、分析梳理

有了前面的分析那么我们可以梳理这个故障发生的原因如下：

  • 1、有一个在B表上长期未提交的DML
    语句会在innodb层对B表某些数据加innodb row lock。
  • 2、由步骤1引起了CREATE TABLE A AS SELECT B的堵塞
    因为RR模式下SELECT B必然对B表上满足的数据上锁，因为步骤1已经加锁所以触发等待，STATE为sending data。
  • 3、由步骤2引起了其他语句的堵塞
    因为CRATE TABLE A AS SELECT B在A表建立完成之前会上MDL_EXCLUSIVE(X),这把锁会堵塞其他全部的关于A表的语句，包括DESC/SHOW TABLE STATUS/USE DB(非-A) 这种只上MDL_SHARED_HIGH_PRIO(SH)MDL LOCK 的语句。STATE统一为Waiting for table metadata lock。

五、模拟测试

测试环境：

  • 5.7.14
  • GITD关闭
  • RR隔离级别
  • 使用脚本：
create table b (id int);
insert into b values(1);
set global innodb_lock_wait_timeout=1000;
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl';
select * from performance_schema.metadata_locks\G
(请重新连接让参数生效)

步骤如下：

session1 session2 session3 session4
--- --- use test; ---
use test;begin; delete from b; --- --- ---
--- use test;create table a asselect * from b;(由于b表innodb row lock堵塞) --- ---
--- --- show table status like 'a';(由于a表MDL LOCK堵塞) ---
--- --- --- use test(由于a表MDL LOCK堵塞)

最后我们看到的等待状态如下：

mysql> select id,COMMAND,STATE, INFO,TIME from information_schema.processlist;
+----+------------+---------------------------------+------------------------------------------------------------------------+------+
| id | COMMAND    | STATE                           | INFO                                                                   | TIME |
+----+------------+---------------------------------+------------------------------------------------------------------------+------+
|  9 | Query      | executing                       | select id,COMMAND,STATE, INFO,TIME from information_schema.processlist |    0 |
|  7 | Query      | Sending data                    | create table a as                                  select * from b     |   20 |
| 10 | Field List | Waiting for table metadata lock |                                                                        |   12 |
|  5 | Sleep      |                                 | NULL                                                                   |  171 |
|  6 | Query      | Waiting for table metadata lock | show table status  like 'a'                                            |   18 |
+----+------------+---------------------------------+------------------------------------------------------------------------+------+

这样我们就完美的模拟出线上的状态，如果我们杀掉session1中的事物，自然就全部解锁了，让我们再来看一下performance_schema.metadata_locks中的输出：

mysql> SELECT * FROM performance_schema.metadata_locks where object_name='a' \G
*************************** 1. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733999179328
            LOCK_TYPE: SHARED
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: GRANTED
               SOURCE: sql_parse.cc:6314
      OWNER_THREAD_ID: 40
       OWNER_EVENT_ID: 1615
*************************** 2. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733663338832
            LOCK_TYPE: SHARED_HIGH_PRIO
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: PENDING
               SOURCE: sql_base.cc:2821
      OWNER_THREAD_ID: 41
       OWNER_EVENT_ID: 1613
*************************** 3. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: test
          OBJECT_NAME: a
OBJECT_INSTANCE_BEGIN: 140733797433200
            LOCK_TYPE: SHARED_HIGH_PRIO
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: PENDING
               SOURCE: sql_base.cc:2821
      OWNER_THREAD_ID: 42
       OWNER_EVENT_ID: 184

我们可以看到如上的输出，但是需要注意LOCK_TYPE: SHARED它不可能堵塞LOCK_TYPE: SHARED_HIGH_PRIO(可以参考附录或者我以前写的MDL LOCK分析的文章)如上文分析这里实际上是做了升级操作升级为了MDL_EXCLUSIVE(X)。

六、结语

  • RC模式下虽然CREATE TABLE A SELECT B中B表不会上任何INNODB ROW LOCK但是如果B表非常大那么A表也会处于MDL_EXCLUSIVE(X)保护下，因此也会触发USE DB\SHOW TABLE STATUS等待的情况。
  • 如果打开GTID不能使用CREATE TABLE A SELECT B这样的语句。
  • 对于DML/DDL混用的系统一定要注意并发，就像本例中如果注意到高并发下的情况可以想办法避免。
  • 这个案列再次说明了长期不提交的事物可能引发悲剧，所以建议监控超过N秒没结束的事务。

七、附录

  • MDL LOCK TYPE
MDL_INTENTION_EXCLUSIVE(IX)
MDL_SHARED(S)
MDL_SHARED_HIGH_PRIO(SH)
MDL_SHARED_READ(SR)
MDL_SHARED_WRITE(SW)
MDL_SHARED_WRITE_LOW_PRIO(SWL)
MDL_SHARED_UPGRADABLE(SU)
MDL_SHARED_READ_ONLY(SRO)
MDL_SHARED_NO_WRITE(SNW)
MDL_SHARED_NO_READ_WRITE(SNRW)
MDL_EXCLUSIVE(X)
  • 兼容性矩阵
      Request  |  Granted requests for lock                   |
        type    | S  SH  SR  SW  SWLP  SU  SRO  SNW  SNRW  X  |
      ----------+---------------------------------------------+
      S         | +   +   +   +    +    +   +    +    +    -  |
      SH        | +   +   +   +    +    +   +    +    +    -  |
      SR        | +   +   +   +    +    +   +    +    -    -  |
      SW        | +   +   +   +    +    +   -    -    -    -  |
      SWLP      | +   +   +   +    +    +   -    -    -    -  |
      SU        | +   +   +   +    +    -   +    -    -    -  |
      SRO       | +   +   +   -    -    +   +    +    -    -  |
      SNW       | +   +   +   -    -    -   +    -    -    -  |
      SNRW      | +   +   -   -    -    -   -    -    -    -  |
      X         | -   -   -   -    -    -   -    -    -    -  |
  • 等待队列优先级矩阵
    A priority matrice specified by it looks like:

       Request  |         Pending requests for lock          |
        type    | S  SH  SR  SW  SWLP  SU  SRO  SNW  SNRW  X |
      ----------+--------------------------------------------+
      S         | +   +   +   +    +    +   +    +     +   - |
      SH        | +   +   +   +    +    +   +    +     +   + |
      SR        | +   +   +   +    +    +   +    +     -   - |
      SW        | +   +   +   +    +    +   +    -     -   - |
      SWLP      | +   +   +   +    +    +   -    -     -   - |
      SU        | +   +   +   +    +    +   +    +     +   - |
      SRO       | +   +   +   -    +    +   +    +     -   - |
      SNW       | +   +   +   +    +    +   +    +     +   - |
      SNRW      | +   +   +   +    +    +   +    +     +   - |
      X         | +   +   +   +    +    +   +    +     +   + |

作者微信：


文章标签：
云数据库 RDS MySQL 版
关系型数据库
Shell
MySQL
网络安全
SQL
关键词：
云数据库 RDS MySQL 版use
云数据库 RDS MySQL 版db
云数据库 RDS MySQL 版堵塞
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
重庆八怪
目录
相关文章
听风de歌
|
关系型数据库 MySQL 数据库
表格存储有类似mysql的use的切换方式吗
表格存储有类似mysql的use的切换方式吗？
听风de歌
66 3
VipSoft
|
4月前
|
数据采集 关系型数据库 MySQL
大数据-业务数据采集-FlinkCDC The MySQL server is not configured to use a ROW binlog_format
大数据-业务数据采集-FlinkCDC The MySQL server is not configured to use a ROW binlog_format
VipSoft
45 1
兀码
|
6月前
|
SQL 关系型数据库 MySQL
使用mysql数据库的binlog应对故障
【6月更文挑战第1天】本文介绍`mysql的 binlog`工具用于解析MySQL的二进制日志，转换为可执行的SQL语句，主要用于数据库主从复制和增量恢复。定期备份和binlog推送能实现故障时的数据恢复。
兀码
269 9
使用mysql数据库的binlog应对故障
玉米侠爱吃玉米
|
7月前
|
SQL 关系型数据库 MySQL
mysql 故障排除与优化
mysql 故障排除与优化
玉米侠爱吃玉米
74 2
极客小俊
|
关系型数据库 MySQL 数据库
MySQL设置 not null 约束 提示 invalid use of null value 问题出现原因及解决
解决方案
极客小俊
455 0
MySQL设置 not null 约束 提示 invalid use of null value 问题出现原因及解决
DevOps和k8s全栈技术
|
SQL 关系型数据库 MySQL
mysql常见故障汇总和处理
mysql常见故障汇总和处理
DevOps和k8s全栈技术
269 0
阿里云社区
|
存储 关系型数据库 分布式数据库
云原生关系型数据库Polar DB MySQL版（二）
云原生关系型数据库Polar DB MySQL版（二）
阿里云社区
230 0
阿里云社区
|
存储 关系型数据库 MySQL
云原生关系型数据库Polar DB MySQL版（一）
云原生关系型数据库Polar DB MySQL版（一）
阿里云社区
279 0
菊头蝙蝠
|
7月前
|
缓存 NoSQL 关系型数据库
MySQL缓存策略（一致性问题、数据同步以及缓存故障）
MySQL缓存策略（一致性问题、数据同步以及缓存故障）
菊头蝙蝠
205 1
王同学睡醒了
|
关系型数据库 MySQL
【XAMPP启动mysql报错】Port 3306 in use by ““C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld“……
【XAMPP启动mysql报错】Port 3306 in use by ““C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld“……
王同学睡醒了
291 0

热门文章

最新文章

  • 1
    RDS入门——Excel文件转存到RDS数据库实践
  • 2
    PostgreSQL SQL HINT的使用
  • 3
    mysql安装过程
  • 4
    Mysql数据库初始化后更改数据存储目录
  • 5
    MySQL学习笔记_2_MySQL创建数据表（上）
  • 6
    MySQL服务器 IO 100%的案例分析
  • 7
    MySQL和Oracle的添加字段的处理差别
  • 8
    [MySQL]命令行工具和基本操作
  • 9
    PostgreSQL:系统表pg_attribute膨胀解决方案
  • 10
    mysql中的时间函数---运维常用
  • 1
    Java医院绩效考核系统源码B/S+avue+MySQL助力医院实现精细化管理
    76
  • 2
    Linux对MySQL语法校验
    89
  • 3
    【MySQL系列笔记】分库分表
    204
  • 4
    mysql 设置环境变量与未设置环境变量连接数据库的区别
    161
  • 5
    服务器Linux系统配置mysql数据库主从自动备份
    214
  • 6
    mysqlTools 一分钟部署安装本mysql多个版本，解锁繁琐部署过程
    419
  • 7
    golang使用gorm操作mysql3，数据查询
    97
  • 8
    golang使用gorm操作mysql2
    61
  • 9
    golang使用gorm操作mysql1
    112
  • 10
    Hbase与MySQL对比，区别是什么？
    303

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL
  • One Box：解读事务与分析一体化数据库HybridDB for MySQL
  • 如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进

    • 相关实验场景

    更多
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 5分钟上手Flink MySQL连接器
  • 云端MySQL的安装及应用
  • 手动部署MySQL数据库（Alibaba Cloud Linux 2）
  • 手动部署MySQL数据库（CentOS 7）

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    fs.oss.accessKeyId和fs.oss.accessKeySecret。