首页 > 问答 > 关键词 > MySQL最新资讯 > 正文

为什么MySQL默认隔离级别是RR

2020-07-02 11:35 · 稿源:数据库干货铺

曾多次听到“MySQL为什么选择RR为默认隔离级别”的问题,其实这是个历史遗留问题,当前以及解决,但是MySQL的各个版本沿用了原有习惯。历史版本中的问题是什么,本次就通过简单的测试来说明一下。

1、 准备工作

1.1 部署主从

部署一套主从架构的集群,创建过程较简单,可以参考历史文章部署 MySQL主从复制搭建 部署一主一从即可。

 1.2 创建测试表及数据

在主库中创建表及测试数据

mysql> create table users(id int primary key auto_increment,user_name varchar(20),c_id tinyint(4),c_note varchar(50),key c_id(c_id)) engine=innodb;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into users values(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0mysql> create table  class(c_id int primary key ,c_name  varchar(1),c_note varchar(50)) engine=innodb;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into class values(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

2、 RR隔离级别 

MySQL默认的隔离级别为 RR(Repeatable Read),在此隔离级别下,对比binlog格式为ROW、STATEMENT是否会造成主从数据不一致

2.1  ROW格式

其实不用测试大家也应该对RR级别下ROW格式的binlog有信心,但是,万事皆需实践检验。

步骤说明如下:

  • 步骤1 -   分别查看两个会话中的事务隔离级别及binlog格式(隔离级别均为RR,binlog为ROW格式)
  • 步骤2 -   SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 5 条记录均更新,并将c_note内容更新为 t1
  • 步骤3-   SESSION B 开启事务,准备删除class表中 c_id等于 2 的记录,此时无法更新,处于阻塞状态,因为在RR级别下需要保证重复读。达到所等待超时时间后将会报错。
  • 步骤4-   SESSION A 提交事务(此步骤也可以在步骤 3 时操作,结果不一样,后续步骤中将采用此方式)
  • 步骤5-   SESSION B 重启事务,再次删除class表中 c_id等于 2 的记录,此时提交可以成功了,成功删除了一条记录
  • 步骤6-   SESSION A  开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 3 条记录更新成功,并将c_note内容更新为 t2,有 2 条记录因为c_id不存在与class表中,因此不会更新
  • 步骤7-  分别在SESSON A和SESSION B查看users表中的内容,结果一致
  • 步骤8-  在从库查看users表中的内容,数据与主库一致

具体步骤如下:

 
步骤SESSION A

SESSION B

1

mysql>show  variables like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.00 sec)

mysql>show  variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.00 sec)

mysql>show  variables like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.00 sec)

mysql>show  variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.01 sec)

2

mysql>set autocommit=0;

mysql>update users set c_note='t1' where c_id in (select  c_id from  class);

Query OK, 5 rows affected (0.00 sec)

Rows matched: 5  Changed: 5  Warnings: 0

3

mysql>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql>delete  from class where c_id=2;

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

4

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

5

mysql>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql>delete  from class where c_id=2;

Query OK, 1 row affected (0.00 sec)

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

6

mysql>update users set c_note='t2' where c_id in (select  c_id from  class);

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 0

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

7

mysql>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙权      |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

mysql>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙权      |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

8

在从库查看数据

root@testdb:3307 12:02:20>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙权      |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

2.2  STATEMENT格式

为了和之前的步骤一致,先初始化数据

root@testdb:3306 12:14:27>truncate tableusers;
Query OK, 0 rows affected (0.08 sec)
root@testdb:3306 12:14:29>truncate tableclass;
Query OK, 0 rows affected (0.04 sec)
root@testdb:3306 12:14:50>insert into users values(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙 权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0root@testdb:3306 12:15:10>insert into class values(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

再将binlog日志格式改为STATAMENT格式(全局及会话级都改一下,或者修改全局变量后重新登录也行,当然 只改会话级别的也可以测试),然后 再次进行测试。

步骤说明如下:

  • 步骤1 -   分别查看两个会话中的事务隔离级别及binlog格式(隔离级别均为RR,binlog为STATENENT格式)
  • 步骤2 -   SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 5 条记录均更新,并将c_note内容更新为 t1
  • 步骤3-   SESSION B 开启事务,准备删除class表中 c_id等于 2 的记录,此时无法更新,处于阻塞状态,立即进行步骤4
  • 步骤4-    SESSION A 在SESSION B执行commit的动作,则SESSION B的删除操作可以执行通过,但注意class表的数据两个SESSION中查看到的是不一样的
  • 步骤5-   此时SESSION B执行commit,否则后面session A 更新数据时也会阻塞。此时如果SESSION A不执行commit,查看class表的结果也是不一样的,如步骤中的情况
  • 步骤6-   SESSION A  开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 3 条记录更新成功,并将c_note内容更新为 t2,另外 2 条记录虽然本此时查看class表中存在对应的c_id,但是不会更新,此时提交事务,然后再次查看class的内容,结果和SESSION B 查看的结果一致了(幻读)
  • 步骤7-  在从库查看users、class表中的内容,数据与主库一致
步  骤SESSION ASESSION B
1               

mysql>show  variables  like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.01 sec)

mysql>show  variables  like '%binlog_format%';

+---------------+-----------+

| Variable_name | Value     |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.01 sec)

mysql>show  variables  like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.01 sec)

mysql>show  variables  like '%binlog_format%';

+---------------+-----------+

| Variable_name | Value     |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.01 sec)

2

root@testdb:3306 12:37:04>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:37:17>update users set c_note='t1' where c_id in (select  c_id from  class);

Query OK, 5 rows affected, 1 warning (0.00 sec)

Rows matched: 5  Changed: 5  Warnings: 1

3

root@testdb:3306 12:28:25>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:38:06>delete  from class where c_id=2;

Query OK, 1 row affected (4.74 sec)

4

root@testdb:3306 12:38:09>commit;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:38:13>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t1     |

|  3 | 孙 权     |    3 | t1     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t1     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3306 12:39:07>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    2 | 蜀     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

4 rows in set (0.00 sec)

5

root@testdb:3306 12:38:13>commit;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:39:56>select *  from class ;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

6

root@testdb:3306 12:52:23>update users set c_note='t2' where c_id in (select  c_id from  class);

Query OK, 3 rows affected, 1 warning (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 1

root@testdb:3306 12:52:45>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    2 | 蜀     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

4 rows in set (0.00 sec)

root@testdb:3306 12:52:49>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙 权     |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.01 sec)

root@testdb:3306 12:53:03>commit;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:53:06>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙 权     |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3306 12:53:11>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

7

查看从库数据

root@testdb:3307 12:44:22>select  * from  class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

3 rows in set (0.01 sec)

root@testdb:3307 12:57:07>select  * from  users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙 权     |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

也就是此时主从结果也是一致的,原因在于,binlog里存储的语句顺序如下:

binlog里的顺序语句内容
1

update users set c_note='t1' where c_id in (select  c_id from  class);

2delete  from class where c_id=2;
3update users set c_note='t2' where c_id in (select  c_id from  class);

与主库执行的顺序是一致的,因此,主从的结果是一致的。

3、 RC隔离级别 

3.1  ROW格式

为了和之前的步骤一致,先初始化数据

root@testdb:3306 12:14:27>truncate tableusers;
Query OK, 0 rows affected (0.08 sec)
root@testdb:3306 12:14:29>truncate tableclass;
Query OK, 0 rows affected (0.04 sec)
root@testdb:3306 12:14:50>insert into users values(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙 权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0root@testdb:3306 12:15:10>insert into class values(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

再将binlog日志格式改为STATAMENT格式(全局及会话级都改一下,或者修改全局变量后重新登录也行,当然 只改会话级别的也可以测试),然后 再次进行测试。

步骤说明如下:

  • 步骤1 -   分别查看两个会话中的事务隔离级别及binlog格式(隔离级别均为RC,binlog为ROW格式)
  • 步骤2 -   SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 5 条记录均更新,并将c_note内容更新为 t1
  • 步骤3-   SESSION B 开启事务,准备删除class表中 c_id等于 2 的记录,此时不会像RR事务隔离级别那样处于阻塞状态,而是可以直接执行通过
  • 步骤4-   此时SESSION A查看class数据还是删除前的,因为session B 暂未提交
  • 步骤5-   SESSION B 提交事务,
  • 步骤6-   更新users 表中c_id字段存在于class表中的记录,结果为 3 条记录更新成功,并将c_note内容更新为 t2
  • 步骤7-  在从库查看users、class表中的内容,数据与主库一致
步  骤SESSION ASESSION B
1               

root@testdb:3306 01:25:24>show  variables  like '%iso%';

+-----------------------+----------------+

| Variable_name         | Value          |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

| tx_isolation          | READ-COMMITTED |

+-----------------------+----------------+

2 rows in set (0.01 sec)

root@testdb:3306 01:25:36>show  variables  like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.01 sec)

root@testdb:3306 01:24:57>show  variables  like '%iso%';

+-----------------------+----------------+

| Variable_name         | Value          |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

| tx_isolation          | READ-COMMITTED |

+-----------------------+----------------+

2 rows in set (0.01 sec)

root@testdb:3306 01:25:39>show  variables  like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.00 sec)

2

root@testdb:3306 01:27:55>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 01:28:27>update users set c_note='t1' where c_id in (select  c_id from  class);

Query OK, 5 rows affected (0.00 sec)

Rows matched: 5  Changed: 5  Warnings: 0

3

root@testdb:3306 01:26:07>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 01:28:37>delete  from class where c_id=2;

Query OK, 1 row affected (0.00 sec)

4

root@testdb:3306 01:28:27>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    2 | 蜀     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

4 rows in set (0.00 sec)

5

root@testdb:3306 01:28:41>commit;

Query OK, 0 rows affected (0.00 sec)

6

root@testdb:3306 01:28:59>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

3 rows in set (0.01 sec)

root@testdb:3306 01:29:13>update users set c_note='t2' where c_id in (select  c_id from  class);

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 0

root@testdb:3306 01:29:26>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

root@testdb:3306 01:29:31>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙 权     |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3306 01:29:38>commit;

7

查看从库数据

 root@testdb:3307 01:40:32>select  * from  users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 刘备      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孙 权     |    3 | t2     |

|  4 | 关羽      |    2 | t1     |

|  5 | 司马懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3307 01:40:35>select  * from  class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吴     | NULL   |

|    4 | 晋     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

也就是此时主从结果也是一致的。

3.2  STATEMENT格式

因为当前版本已经不支持RC+STATEMENT组合下数据的操作,否则将报如下错误:

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

因此单纯根据步骤讲解

步骤SESSION  ASESSION B
1

mysql>set autocommit=0;

mysql>update users set c_note='t1' where c_id in (select  c_id from  class);

2

mysql>set autocommit=0;

mysql>delete  from class where c_id=2;

mysql>commit;

3mysql>update users set c_note='t2' where c_id in (select  c_id from  class);
4commit;

因为binlog是按照commit时间的顺序保存,因此上述步骤在binlog里会以如下顺序存储:

binlog里的顺序语句内容
1

delete  from class where c_id=2;

2update users set c_note='t1' where c_id in (select  c_id from  class);
3update users set c_note='t2' where c_id in (select  c_id from  class);

从库通过binlog应用后,最终的结果将导致主库的数据不一样(具体案例后续安装低版本后演示)。

因而,此种场景下很容易导致数据不一样。

4、总结

通过上述的实践,可以发现在RR级别下,binlog为任何格式均不会造成主从数据不一致的情况出现,但是当低版本MySQL使用RC+STATEMENT组合时(MySQL5.1. 5 前只有statement格式)将会导致主从数据不一致。当前这个历史遗漏问题以及解决,大家可以将其设置为RC+ROW组合的方式(例如ORACLE等数据库隔离级别就是RC),而不是必须使用RR(会带来更多的锁等待),具体可以视情况选择。

本文转载自微信公众号【数据库干货铺】。

网友热搜:

  • 相关推荐
  • 大家在看
  • MySQL忘记密码怎么办 密码重置详细教程

    如果忘记密码,对于MySQL而言处理起来也相对比较简单。但需要修改配置,重启数据库。可以按照如下步骤处理。

  • MySQL敏感数据怎么加密 数据加密解密教程

    大数据时代的到来,数据成为企业最重要的资产之一,数据加密的也是保护数据资产的重要手段。本文主要在结合学习通过MySQL函数及Python加密方法来演示数据加密的一些简单方式。

  • MySQL怎么连接 全部连接方式汇总

    1. 连接方式1.1 方式1 /usr/local/mysql5.7/bin/mysql -p此方法默认采用root@localhost用户登录,1.2 方式2/usr/local/mysql5.7/bin/mysql -uroot -p -S /app/data/mysql3307/tmp/mysql.sock1.3 方式3/usr/local/mysql5.7/bin/mysql -uroot -p -h 127.0.0.1 -P3307此方式的用户和方式 2 的不同,如下 root@localhost 和root@127.0.0.1是不同的用户1.4 方式4 /usr/local/mysql5.7/bin/mysql -uroot -p -h localhost -P3307此方式和?

  • MySQL怎么删除#sql开头的临时表

    巡检时发现服务器磁盘空间不足,通过查看大文件进行筛选是发现有几个#sql开头的文件,且存在超过100G及10G以上的文件。

  • MySQL一直自动重启解决办法

    近期,测试环境出现了一次MySQL数据库不断自动重启的问题,导致的原因是强行kill -9 杀掉数据库进程导致,报错信息如下:2019-07-24T01:14:53.769512Z 0 [Note] Executing SELECT * FROM INFORMATION_SCHEMA.TABLES; to get a list of tables using the deprecated partition engine. You may use the startup option --disable-partition-engine-check to skip this check.2019-07-24T01:14:53.769516Z 0 [Note] Beginning of

  • MYSQL的ibtmp1文件太大怎么处理

    1. 啥情况呀测试环境机器磁盘空间不足的告警打破了下午的沉寂,一群人开始忙活着删数据。但是,不久前刚清理了一波数据,测试环境在没做压测的情况下不至于短短一个月不到就涨了200G数据,于是,我悄悄的进入数据目录下,发现一个不寻常的点,ibtmp1 文件有192G ll -hibtmp1 -rw-r----- 1 mysql mysql 192G Aug 12 16:20 ibtmp12. 怎么处理2.1 简单说明ibtmp1 是非压缩的innodb临时表的独立表空间,通过innodb_temp_data_file_pat

  • MySQL数据备份及恢复教程 巧用xtrabackup工具备份恢复

    本文将通过应用更为普遍的物理备份工具xtrabackup来演示数据备份及恢复的第二篇内容。

  • 为避免种族歧视,MySQL宣布删除黑名单白名单等术语

    MySQL数据库的开发人员日前宣布,计划在数据库源代码和文档中停止使用并替换 master、 slave、 blacklist(黑名单)和whitelist(白名单)等术语。

  • MySQL传统点位复制在线转为GTID模式复制

    1. GTID优缺点MySQL传统点位复制在5. 7 版本前是主要的主从复制模式,而随着MySQL5. 6 版本引入GTID,并且MySQL5. 7 进行各方面的优化以后,在mySQL5.7(尤其是MySQL5.7.6)版本后GTID模式的主从复制方式成为一个新的选择方式。要使用GTID模式,首先也需知其优缺点,其主要的优缺点如下:1.1 优点a) 更简单的实现failover,无需找log_file和log_Pos。b) 更简单的搭建主从复制。c) 复制集群有一个统一的方式识别复制位置,给集群管理

  • 黑名单、白名单完全不能用了!MySQL、Twitter等纷纷删除

    作为全球第二大流行数据库,MySQL也受到了众所周知事件的影响,不得不做出一些调整。MySQL开发人员今天宣布,计划在数据库源文件、文档中停止使用master(主)、slave(从)、blacklist(黑名单)、

  • BBC蛋炒饭教程气坏亚洲网友 蛋炒饭教程视频观看地址

    【BBC蛋炒饭教程气坏亚洲网友】据媒体报道,近日马来西亚 Youtube 博主mrnigelng发布了一则吐槽BBC美食频道蛋炒饭教程的视频。新闻发出后引起了网友的热议。

  • 花呗怎么取消征信 花呗取消征信记录教程

    最近花呗正式的接入了央行征信,很多朋友想知道怎么取消这个征信记录,下面就来为大家分享一下花呗取消征信记录教程。

  • 紫塞秋风莫高窟晚上禁地怎么进去 详细进入方法教程

    紫塞秋风很多玩家在做到任务莫高窟这个地方的时候,如果做了支线就不会让你进去,那么怎么才能再进去呢?下面就来为大家详细的介绍一下进入莫高窟的办法。

  • 《天气之子》免费观看教程,葫芦视频讲解

    自从电影院开始复工,很多片子也陆陆续续开始上映了。《天气之子》这部日本动漫,相信有的朋友已经看过了,影片在国内上映自 2019 年 11 月 1 日。这也是无数的动漫迷期盼 3 年已久的新海诚新作,整个故事时长 2 个小时左右。新海诚的这部新作,主要是描述一名叫“天野阳菜”的女主,她在一年前意外获得了“能够100%放晴天气”的超能力,但是几乎没有怎么使用过,直到男主“森岛帆高”的出现,事情自此变得不再一样。然而聪明的男?

  • 微信视频号怎么涨粉 快速涨粉技巧教程

    微信视频号随着腾讯的开放和推广是越来越火了,很多朋友都想做一个微信视频号进行涨粉,所以今天就来为大家分享一下微信视频号的涨粉教程,帮助大家快速涨粉。

  • BBC蛋炒饭教程气坏亚洲网友,主持人表示自己是无辜的

    炒饭在亚洲国家里可以说是一道十分简单又很普及的食物,但最近英国广播电视台BBC的一个炒饭制作教程却引发了很多亚洲网友的不满,原因是他们在制作的过程中,将煮熟的米饭放在水龙头下冲洗。

    BBC
  • BBC蛋炒饭教程气坏亚洲网友,居然用水冲洗饭

    英国BBC电视台曾推出过多部纪录片,如《地球脉动》、《蓝色星球》等均获得了好评,但近日他们推出的一个有关炒饭的美食视频却遭到了大量亚洲网友的批评,原因竟是他们的食谱要求在饭蒸好之后还要用水冲洗。

    BBC
  • 新手如何购买比特币?OKEx买币详细教程

    比特币在过去七天里波动很大。这种加密货币在 6 月 1 日突破了 1 万美元,在主要的加密货币交易所甚至一度达到 10450 美元的高度,这一上涨也清算了BitMEX价值数千万美元的空头头寸。在推特上颇受欢迎的分析师“凯撒”(Caesar)表示,如果该加密货币可以通过每日收盘高于该水平来果断地宣称该水平为支撑位,那么接下来将会有更大的动作。他说:“如果比特币能够重新获得这些高点,并且每天收盘都在接近高点,我认为我们可以开始瞄准

  • 对马岛之魂全部传说故事图文攻略 7个传说故事接取完成教程

    对马岛之魂中一共是有7个传说故事可以接取,并且可以获得很多好的道具装备奖励,下面就来为大家分享一下对马岛之魂全部传说故事图文攻略。

  • 电视也能截图?当贝市场分享详细图文教程

    当我们在电视时,想要把某一个画面分享给朋友时,往往是通过手机拍摄电视画面,但这种方法在拍摄时会受到周围灯光的影响,拍出来不的画质并不清晰。那么,你可能需要直接电视截图,接下来,小编就来分享电视截图的教程了!方法一:悟空遥控器首先要在智能电视和手机上分别下载一个悟空遥控,在悟空遥控器的工具箱中就有截屏这个功能。将智能电视和手机连接同一个局域网,成功连接后,点击截屏就可以成功将电视桌面截下。方法二:远程?

  • 参与评论
文明上网理性发言,请遵守新闻评论服务协议
  • 热门标签