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

MySQL5.7 GTID 运维实战

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

GTID 和 START SLAVE

  • START SLAVE 语法
START SLAVE [thread_types] [until_option] [connection_options]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type:
    IO_THREAD | SQL_THREAD

until_option:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
          |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
          |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
          |   SQL_AFTER_MTS_GAPS  }


* SQL_BEFORE_GTIDS = $gitd_set ： $gtid_set之前的gtid都会被执行

eg. START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

表示，当SQL_thread 执行到3E11FA47-71CA-11E1-9E33-C80AA9429562:10 的时候停止，下一个事务是11

* SQL_AFTER_GTIDS = $gitd_set : $gtid_set之前，以及$gtid_set包含的gtid都会被执行

eg. START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

表示，当SQL_thread 执行到3E11FA47-71CA-11E1-9E33-C80AA9429562:56 的时候停止，56是最后一个提交的事务。
  • 如何从multi-threaded slave 转化成 single-threaded mode
START SLAVE UNTIL SQL_AFTER_MTS_GAPS;

SET @@GLOBAL.slave_parallel_workers = 0;

START SLAVE SQL_THREAD;

GTID 和 upgrade

如果 --gtid-mode=ON ，那么在使用upgrade时候，不推荐使用--write-binlog 选项。
因为，mysql_upgrade 会更新Myisam引擎的系统表. 而同时更新transction table 和 non-trasaction table 是gtid所不允许的

GTID 和 mysql.gtid_executed

  • gtid_mode = (ON|ON_PERMISSIVE), bin_log = off
gtid 会实时的写入到mysql.gtid_executed表中，且根据executed_gtids_compression_period=N来压缩
  • gtid_mode = (ON|ON_PERMISSIVE), bin_log = on
gtid 不会实时的写入到mysql.gtid_executed，executed_gtids_compression_period会失效。
只有当binlog rotate或者mysql shutdown的时候才会写入mysql.gtid_executed

如果master 异常shutdown，gtid还没有写入到mysql.gtid_executed怎么办呢？
这种场景，一般通过mysql recover机制写入到mysql.gtid_executed中

GTID 和 gtid_next

http://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_gtid_next

  • 三种取值
* AUTOMATIC: Use the next automatically-generated global transaction ID.

* ANONYMOUS: Transactions do not have global identifiers, and are identified by file and position only.

* A global transaction ID in UUID:NUMBER format.
  • QA: GTID 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-50 对应的事务顺序，从小到大，一定是顺序执行的吗？

答案：错，一般情况下事务是从小到大，顺序执行的。 但是如果再MTS场景，或者是人工设置gtid_next的情况下，就可能不是顺序执行了

dba:(none)> show master status;
+--------------------+----------+--------------+------------------+-------------------------------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+--------------------+----------+--------------+------------------+-------------------------------------------+
| xx.000009 |     1719 |              |                  | 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-46 |
+--------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

dba:(none)> set gtid_next='0923e916-3c36-11e6-82a5-ecf4bbf1f518:50';
Query OK, 0 rows affected (0.00 sec)

dba:lc> insert into gtid_1 values(5);
Query OK, 1 row affected (0.00 sec)

dba:lc> set gtid_next=AUTOMATIC;
Query OK, 0 rows affected (0.00 sec)


dba:lc> flush logs;
Query OK, 0 rows affected (0.01 sec)

dba:lc> show master status;
+--------------------+----------+--------------+------------------+----------------------------------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                            |
+--------------------+----------+--------------+------------------+----------------------------------------------+
| xx.000010 |      210 |              |                  | 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-46:50 |
+--------------------+----------+--------------+------------------+----------------------------------------------+
1 row in set (0.00 sec)

dba:lc> insert into gtid_1 values(6);
Query OK, 1 row affected (0.00 sec)

dba:lc> insert into gtid_1 values(6);
Query OK, 1 row affected (0.00 sec)

dba:lc> insert into gtid_1 values(6);
Query OK, 1 row affected (0.00 sec)

dba:lc> show master status;
+--------------------+----------+--------------+------------------+-------------------------------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+--------------------+----------+--------------+------------------+-------------------------------------------+
| xx.000010 |     1125 |              |                  | 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-50 |
+--------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)


在这里面，很明显0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-50 事务执行顺序为： 1-46(最先执行) ， 50（其次执行） ， 47-49（最后执行）

GTID 和 MHA

请参考MHA源码解析

  • GTID模式下，需要relay-log吗？purge_relay_log设置为on可以吗？
* replication 架构

host_1(host_1:3306) (current master)
 +--host_2(host_2:3306 candidate master)
 +--host_3(host_3:3306 no candidate)

* 模拟：
1. 大量并发的写入，一直持续的往host_1写数据,造成并发写入很大的样子
2. host_2： stop slave ， 造成host_2 延迟master很多的样子
3. host_1:  purge binary logs， 造成master删掉了日志，导致host_2 修复的时候拿不到master的最新binlog
4. host_3:  一直正常同步master，拥有最新的binlog
5. host_3: flush logs; purge_relay_log=on; flush logs；一直循环flush logs，造成host_3已经将最新的relay log删掉了，host_2 是肯定拿不到host_3的relay 来修复自己了
6. 好了，一切条件均已经准备完毕，这个时候让master 宕机，这样就能模拟出在relay log没有的情况下，是否可以正常完成mha 切换了

...............


7. 结果完成了正常切换，那mha是怎么再gtid模式下，在没有relay log的情况下，正常切换的恩？
8. 原理：host_2发现自己不是最新的slave，所以就去change master到host_3,通过host_3的binlog来恢复
9. 最后，当host_2和host_3都一致的情况下，再让host_3 重新指向host_2，完毕...

*结论： gtid模式下，mha恢复切换的原理是不需要relay log的，只需要binlog

GTID 和 备份（物理备份+逻辑备份）

物理备份：xtrabackup，其他等
逻辑备份：mysqldump，mydumper，mysqlpump等

  • 物理备份
备份的时候，只要在备份的时候记录下Executed_Gtid_Set($gtid_dump)即可，这个可以用于重新change master;

reset master;
SET @@GLOBAL.GTID_PURGED='$gtid_dump';
change master to master_auto_position=1;
  • 逻辑备份
* mysqldump 中 sql_log_bin 默认是关闭的。 SET @@SESSION.SQL_LOG_BIN= 0;   所以这里用途非常重要

* 如果dump文件，你要在master上执行，那么必须这样备份： mysqldump xx  --set-gtid-purged=OFF , 这样dump文件不会有SET @@SESSION.SQL_LOG_BIN= 0存在

* 如果dump文件，你要在slave上执行，想重新搭建一套slave环境。那么必须这样备份： mysqldump xx  --set-gtid-purged=ON

GTID 和 crash safe slave

slave relay log 不完整怎么办？（relay-log-recover=0）
relay-log-recover=1 不考虑，因为它会舍弃掉relay log

  • 为何要讨论这个
* 官方解释：

1) 非GTID模式下，如何保证slave crash safe 呢？
    relay_log_recovery=1，relay_log_info_repository=TABLE，master_info_repository=TABLE,innodb_flush_log_at_trx_commit=1,sync_binlog=1

2) GTID模式下，如何保证slave crash safe呢？
    relay_log_recovery=(1|0)，relay_log_info_repository=TABLE，master_info_repository=TABLE,innodb_flush_log_at_trx_commit=1,sync_binlog=1

以上两种情况配置，可以保证crash safe

这里看到区别就是relay_log_recovery了，gtid可以是any，这就需要讨论下了。

当relay_log_recovery=1时，当mysql crash的时候，会丢弃掉之前获取的relay，所以这个不会产生一致性问题。
当relay_log_recovery=0时
    如果是非GTID模式，因为没办法保证写master_info.log和relay log file之间的原子性，会导致slave有可能多拉取一个事务，这样就有一致性问题。
    如果是GTID模式，因为binlog-dump协议变了，master_info.log已经不用，slave会将已经exected_GTID与retrieve_gtid的并集发送给master，以此来获取没有执行过的gtid，所以没问题。

这里面的retrieve_gtid就是IO_thread从master获取的gtid，会写入到relay log。
  • 模拟relay log不完整的情况

从上面可以知道，relay log的记录非常重要，那么relay log 不完整，会怎么样呢？

1) master 创建一张10G的表，然后执行全表更新操作。
2）这时候，slave就在狂写relay log了
3）此时，去slave kill掉mysql进程
4）这时候，relay log就不完整了

WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set.
This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement.
The event(s) from the partial statement have not been written to output.

总结： relay log不完整，mysql起来后，会重新获取不完整的这个events，sql_thread在回放的时候，如果发现events不完整，会跳过，不会影响到同步。

GTID 和 MTS

MTS_GAPS

  • 如果MTS遇到Gap transction怎么办？
1. 先解决问题

START SLAVE UNTIL SQL_AFTER_MTS_GAPS

2. 考虑设置slave_preserve_commit_order=1

GTID 生产环境中必须考虑的问题

Migration to GTID replication
Non transactionally safe statement will raise errors now
MySQL Performance in GTID
mysql_upgrade script
Errant transactions
Filtration on the slave
Injecting empty transactions
以上问题请参考 GTID原理与实战

GTID 和 online升级

online升级丢数据?
online升级会报错吗？
online升级步骤请参考 GTID原理与实战

  • 故障案例一

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Cannot replicate anonymous transaction when @@GLOBAL.GTID_MODE = ON ...'

两种情况：
1）slave的gtid_mode=on时，却还接受着来自master的non-gtid transaction的时候，会报以上错误。
2）事实上，不管slave的gtid_mode是on，还是off，只要master的gtid_mode=on,那么整个replication slave，都必须是gtid的事务

解决方案：在master上从gtid_mode=ON_PERMISSIVE 设置到 gtid_mode=ON之前，如何保证现在所有non-gtid事务都已经在slave执行完毕了？

很简单，两种方法：

第一种方案：

1) 在master上，当设置gtid_mode=ON_PERMISSIVE的时候，其实就已经产生gtid事务了，这个时候show master status；记下这个位置 $pos

2）然后再每个slave上，执行 SELECT MASTER_POS_WAIT(file, position);

第二种更加直接方案：

0）默认情况下，slave的gtid_mode都是off，所以去slave上show master status 都应该是file，position
1) 先在master上，设置gtid_mode=ON_PERMISSIVE
2）然后再每台slave上再次执行show master status，如果发现结果由file，position 变成 GTID_EXECUTED，那么说明slave已经将non-gtid全部执行完毕了
  • 故障案例二

Last_IO_Error: The replication receiver thread cannot start because the master has GTID_MODE = ON and this server has GTID_MODE = OFF.

slave的gtid_mode=off时，却还接受着来自master的gtid transaction的时候，会报以上错误。

GTID 和 mysqlbinlog

mysqlbinlog 参数：

* --exclude-gtids : 排除这些gtid
* --include-gtids : 只打印这些gtid
* --skip-gtids    : 所有gtid都不打印

可以用--skip-gtids 做传统模式的恢复。但是这个是官方不推荐的。
mysqlbinlog --skip-gtids binlog.000001 >  /tmp/dump.sql

GTID 和 重要函数

gtid_set 用引号扩起来

Name Description
GTID_SUBSET(subset,set) returns true (1) if all GTIDs in subset are also in set
GTID_SUBTRACT(set,subset) returns only those GTIDs from set that are not in subset
WAIT_FOR_EXECUTED_GTID_SET(gtid_set[, timeout]) Wait until the given GTIDs have executed on slave.
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set, timeout) Wait until the given GTIDs have executed on slave
  • GTID_SUBSET(subset,set)

subset 是否是 set 的子集，如果是返回1，不是返回0

dba:(none)> SELECT GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57');
+-----------------------------------------------------------------------------------------------------+
| GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57') |
+-----------------------------------------------------------------------------------------------------+
|                                                                                                   1 |
+-----------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

dba:(none)> SELECT GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:23-25','3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57');
+--------------------------------------------------------------------------------------------------------+
| GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:23-25','3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57') |
+--------------------------------------------------------------------------------------------------------+
|                                                                                                      1 |
+--------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

dba:(none)> SELECT GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
+--------------------------------------------------------------------------------------------------+
| GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','3E11FA47-71CA-11E1-9E33-C80AA9429562:23') |
+--------------------------------------------------------------------------------------------------+
|                                                                                                1 |
+--------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

dba:(none)> SELECT GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:20-25','3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57');
+--------------------------------------------------------------------------------------------------------+
| GTID_SUBSET('3E11FA47-71CA-11E1-9E33-C80AA9429562:20-25','3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57') |
+--------------------------------------------------------------------------------------------------------+
|                                                                                                      0 |
+--------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
  • GTID_SUBTRACT(set,subset)

哪些gtids仅仅是set独有的，subset没有的

dba:(none)> SELECT GTID_SUBTRACT('3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57','3E11FA47-71CA-11E1-9E33-C80AA9429562:21');
+-------------------------------------------------------------------------------------------------------+
| GTID_SUBTRACT('3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57','3E11FA47-71CA-11E1-9E33-C80AA9429562:21') |
+-------------------------------------------------------------------------------------------------------+
| 3e11fa47-71ca-11e1-9e33-c80aa9429562:22-57                                                            |
+-------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

dba:(none)> SELECT GTID_SUBTRACT('3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57','3E11FA47-71CA-11E1-9E33-C80AA9429562:20-25');
+----------------------------------------------------------------------------------------------------------+
| GTID_SUBTRACT('3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57','3E11FA47-71CA-11E1-9E33-C80AA9429562:20-25') |
+----------------------------------------------------------------------------------------------------------+
| 3e11fa47-71ca-11e1-9e33-c80aa9429562:26-57                                                               |
+----------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

dba:(none)> SELECT GTID_SUBTRACT('3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57','3E11FA47-71CA-11E1-9E33-C80AA9429562:23-24');
+----------------------------------------------------------------------------------------------------------+
| GTID_SUBTRACT('3E11FA47-71CA-11E1-9E33-C80AA9429562:21-57','3E11FA47-71CA-11E1-9E33-C80AA9429562:23-24') |
+----------------------------------------------------------------------------------------------------------+
| 3e11fa47-71ca-11e1-9e33-c80aa9429562:21-22:25-57                                                         |
+----------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

以上两个函数可以用来干嘛呢？
通过GTID_SUBSET，master可以知道slave是否是自己的子集，可以很方便的检查数据一致性
通过GTID_SUBTRACT，假设slave是master的子集，那么可以很轻松的将slave没有，master有的gtid发送给slave，以便达到最终一致性

  • WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set, timeout)

timeout 默认为0,表示无限等待slave gtid_set全部执行完毕
如果全部执行完毕，会返回执行的gtid的数量。如果没有执行完，会等待timeout秒。如果slave没有起来，或者没有开启gtid，会返回NULL

dba:lc> SELECT WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-3');
+---------------------------------------------------------------------------------+
| WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-3',1) |
+---------------------------------------------------------------------------------+
|                                                                               0 |
+---------------------------------------------------------------------------------+
1 row in set (0.00 sec)

stop slave;

dba:lc> SELECT WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-3');
+---------------------------------------------------------------------------------+
| WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-3',1) |
+---------------------------------------------------------------------------------+
|                                                                            NULL |  ## 如果slave的IO,SQL thread 没有running，返回NULL，不管gtid set 有木有执行完毕
+---------------------------------------------------------------------------------+
1 row in set (0.00 sec)
  • WAIT_FOR_EXECUTED_GTID_SET(gtid_set[, timeout])

含义跟WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS一样，唯一一个区别就是：如果slave 的replication 线程没有起来，不会返回NULL。

stop slave;

dba:lc> SELECT  WAIT_FOR_EXECUTED_GTID_SET('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-3');
+------------------------------------------------------------------------+
| WAIT_FOR_EXECUTED_GTID_SET('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-3') |
+------------------------------------------------------------------------+
|                                                                      0 |          ## 如果都执行了，返回0 ， 跟slave的IO,SQL thread 起没起来无关
+------------------------------------------------------------------------+
1 row in set (0.00 sec)

dba:lc> SELECT  WAIT_FOR_EXECUTED_GTID_SET('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-4',1);
+--------------------------------------------------------------------------+
| WAIT_FOR_EXECUTED_GTID_SET('0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-4',1) |
+--------------------------------------------------------------------------+
|                                                                        1 |
+--------------------------------------------------------------------------+
1 row in set (1.00 sec)

GTID 的限制和缺点

  • 同事更新nontransactional和transactional的表，会导致gtid问题
  • CREATE TABLE ... SELECT statements 语法对GTID来说是不安全的
  • CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE 对GTID也是不安全的
  • enforce-gtid-consistency 必须设置on，可以避免以上2，3 不安全的statement
  • sql_slave_skip_counter 不允许执行，可以通过 Injecting empty transactions 来解决
  • GTID 和 mysqldump的问题，mysqldump 中 sql_log_bin 默认是关闭的.会导致导入master后，不会写入gtid到binlog. ( 可以通过 --set-gtid-purged=OFF 避免 )
  • GTID and mysql_upgrade, 因为部分系统表是myisam引擎的，会有问题。 （可以通过--write-binlog=off来避免 ）

参考文档

  • 官方资料：

1.5 Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 5.7

5.5.4 mysqldump — A Database Backup Program
5.6.7 mysqlbinlog — Utility for Processing Binary Log Files


13.17 Functions Used with Global Transaction IDs

14.4.2.1 CHANGE MASTER TO Syntax
14.4.2.6 START SLAVE Syntax
14.7.5.34 SHOW SLAVE STATUS Syntax



18.1.3 Replication with Global Transaction Identifiers
    18.1.3.1 GTID Concepts
    18.1.3.2 Setting Up Replication Using GTIDs
    18.1.3.3 Using GTIDs for Failover and Scaleout
    18.1.3.4 Restrictions on Replication with GTIDs
    18.1.5.1 Replication Mode Concepts
    18.1.5.2 Enabling GTID Transactions Online
    18.1.5.3 Disabling GTID Transactions Online
    18.1.6.1 Replication and Binary Logging Option and Variable Reference
    18.1.6.5 Global Transaction ID Options and Variables
    18.3.2 Handling an Unexpected Halt of a Replication Slave
    18.4.1.34 Replication and Transaction Inconsistencies
    18.4.3 Upgrading a Replication Setup


19.2.1.5 Adding Instances to the Group

24.10.7.1 The events_transactions_current Table
24.10.11.6 The replication_applier_status_by_worker Table
  • 第三方资料
> http://www.fromdual.ch/things-you-should-consider-before-using-gtid
> http://www.fromdual.ch/gtid_in_action
> http://www.fromdual.ch/replication-troubleshooting-classic-vs-gtid
> http://www.fromdual.ch/replication-in-a-star
> http://www.fromdual.com/controlling-worldwide-manufacturing-plants-with-mysql
> https://www.percona.com/blog/2014/05/19/errant-transactions-major-hurdle-for-gtid-based-failover-in-mysql-5-6/
> https://www.percona.com/blog/2016/12/01/database-daily-ops-series-gtid-replication-binary-logs-purge/
> https://www.percona.com/blog/2016/11/10/database-daily-ops-series-gtid-replication/
> https://www.percona.com/blog/2015/12/02/gtid-failover-with-mysqlslavetrx-fix-errant-transactions/
> https://www.percona.com/blog/2014/05/09/gtids-in-mysql-5-6-new-replication-protocol-new-ways-to-break-replication/
文章标签：
云数据库 RDS MySQL 版
云数据库 ClickHouse
关系型数据库
数据库管理
MySQL
运维
关键词：
运维实战
云数据库 RDS MySQL 版实战
云数据库 RDS MySQL 版运维
mysql运维
云数据库 RDS MySQL 版gtid
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL，然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
兰春
目录
相关文章
德国都芳最好
|
3月前
|
缓存 关系型数据库 MySQL
MySQL索引策略与查询性能调优实战
在实际应用中，需要根据具体的业务需求和查询模式，综合运用索引策略和查询性能调优方法，不断地测试和优化，以提高MySQL数据库的查询性能。
德国都芳最好
313 66
土木林森
|
3月前
|
Prometheus 运维 监控
智能运维实战：Prometheus与Grafana的监控与告警体系
【10月更文挑战第26天】Prometheus与Grafana是智能运维中的强大组合，前者是开源的系统监控和警报工具，后者是数据可视化平台。Prometheus具备时间序列数据库、多维数据模型、PromQL查询语言等特性，而Grafana支持多数据源、丰富的可视化选项和告警功能。两者结合可实现实时监控、灵活告警和高度定制化的仪表板，广泛应用于服务器、应用和数据库的监控。
土木林森
419 3
周周的奇妙编程
|
1月前
|
运维 自然语言处理 Ubuntu
解锁高效运维新姿势！操作系统智能助手OS Copilot新功能实战测评
阿里云OS Copilot经过多轮迭代，现已支持多端操作系统（包括Ubuntu、CentOS、Anolis OS等）及aarch64架构，极大扩展了其适用范围。新特性包括阿里云CLI调用、系统运维及调优工具的直接调用、Agent模式实装以及复杂任务处理能力。这些更新显著提升了用户体验和效率，特别是在处理紧急情况时，OS Copilot能快速查找并执行命令，节省大量时间和精力。此外，通过自然语言交互，用户可以轻松完成如系统健康检查、文件操作及日志分析等任务。总之，OS Copilot已从内测时的辅助工具进化为合格的贴身管家，极大地简化了日常运维工作。
周周的奇妙编程
391 16
shuj
|
3月前
|
运维 监控 应用服务中间件
自动化运维的利器：Ansible实战应用
【10月更文挑战第41天】在现代IT运维领域，自动化已成为提高效率、减少错误的关键。Ansible作为一种简单而强大的自动化工具，正被越来越多的企业采纳。本文将通过实际案例，展示如何使用Ansible简化日常运维任务，包括配置管理和批量部署等，旨在为读者提供一种清晰、易懂的自动化解决方案。
shuj
56 1
mrq4nk6ni2neg
|
3月前
|
运维 Ubuntu 应用服务中间件
自动化运维工具Ansible的实战应用
【10月更文挑战第36天】在现代IT基础设施管理中，自动化运维已成为提升效率、减少人为错误的关键手段。本文通过介绍Ansible这一流行的自动化工具，旨在揭示其在简化日常运维任务中的实际应用价值。文章将围绕Ansible的核心概念、安装配置以及具体使用案例展开，帮助读者构建起自动化运维的初步认识，并激发对更深入内容的学习兴趣。
mrq4nk6ni2neg
100 4
潇洒洒
|
3月前
|
消息中间件 运维 UED
消息队列运维实战：攻克消息丢失、重复与积压难题
消息队列（MQ）作为分布式系统中的核心组件，承担着解耦、异步处理和流量削峰等功能。然而，在实际应用中，消息丢失、重复和积压等问题时有发生，严重影响系统的稳定性和数据的一致性。本文将深入探讨这些问题的成因及其解决方案，帮助您在运维过程中有效应对这些挑战。
潇洒洒
56 1
土木林森
|
3月前
|
监控 关系型数据库 MySQL
数据库优化：MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型，以及如何创建和维护索引，结合实战案例分析查询执行计划，帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
土木林森
581 1
潇洒洒
|
4月前
|
NoSQL 关系型数据库 MySQL
MySQL与Redis协同作战：优化百万数据查询的实战经验
【10月更文挑战第13天】 在处理大规模数据集时，传统的关系型数据库如MySQL可能会遇到性能瓶颈。为了提升数据处理的效率，我们可以结合使用MySQL和Redis，利用两者的优势来优化数据查询。本文将分享一次实战经验，探讨如何通过MySQL与Redis的协同工作来优化百万级数据统计。
潇洒洒
194 5
土木林森
|
3月前
|
Prometheus 运维 监控
智能运维实战：Prometheus与Grafana的监控与告警体系
【10月更文挑战第27天】在智能运维中，Prometheus和Grafana的组合已成为监控和告警体系的事实标准。Prometheus负责数据收集和存储，支持灵活的查询语言PromQL；Grafana提供数据的可视化展示和告警功能。本文介绍如何配置Prometheus监控目标、Grafana数据源及告警规则，帮助运维团队实时监控系统状态，确保稳定性和可靠性。
土木林森
408 0
土木林森
|
3月前
|
监控 关系型数据库 MySQL
数据库优化：MySQL索引策略与查询性能调优实战
【10月更文挑战第26天】数据库作为现代应用系统的核心组件，其性能优化至关重要。本文主要探讨MySQL的索引策略与查询性能调优。通过合理创建索引（如B-Tree、复合索引）和优化查询语句（如使用EXPLAIN、优化分页查询），可以显著提升数据库的响应速度和稳定性。实践中还需定期审查慢查询日志，持续优化性能。
土木林森
371 0

热门文章

最新文章

  • 1
    美团面试：MySQL为什么 不用 Docker部署？
  • 2
    【深入了解MySQL】优化查询性能与数据库设计的深度总结
  • 3
    详解MySQL字符集和Collation
  • 4
    docker pull mysql:8.0.26提示Error response from daemon: Get “https://registry-1.docker.io/v2/“: EOF错误
  • 5
    数据库连接工具连接mysql提示：“Host ‘172.23.0.1‘ is not allowed to connect to this MySQL server“
  • 6
    MySQL底层概述—1.InnoDB内存结构
  • 7
    MySQL底层概述—2.InnoDB磁盘结构
  • 8
    MySQL原理简介—1.SQL的执行流程
  • 9
    嵌入式C++、STM32、MySQL、GPS、InfluxDB和MQTT协议数据可视化
  • 10
    MySQL 分库分表方案
  • 1
    操作系统控制台 | 让运维也可以点点点
    261
  • 2
    PolarDB 开源基础教程系列 4 日常运维
    18
  • 3
    操作系统控制台体验评测：AI驱动的运维新体验
    36
  • 4
    docker运维查看指定应用log文件位置和名称
    81
  • 5
    AI辅助的运维风险预测：智能运维新时代
    120
  • 6
    智能日志分析：用AI点亮运维的未来
    139
  • 7
    云产品评测｜用操作系统控制台，让运维更简单！
    75
  • 8
    HTTPS 证书自动化运维：https证书管理系统-自动化部署
    36
  • 9
    HTTPS 证书自动化运维：https证书管理系统- 自动化监控
    90
  • 10
    HTTPS 证书自动化运维：https证书管理系统之自动化签发
    47

    • 相关课程

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

    • 相关电子书

    更多
  • 搭建电商项目架构连接MySQL
  • 搭建4层电商项目架构，实战连接MySQL
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布

    • 相关实验场景

    更多
  • MySQL基础-学生管理系统数据库设计
  • 如何快速连接云数据库RDS MySQL
  • MySQL数据库快速部署实践
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 使用CloudLens采集RDS日志并进行审计分析

    • 推荐镜像

    更多
  • mysql
  • oceanbase
  • mariadb
    • 下一篇
    PAI Model Gallery 支持云上一键部署 DeepSeek-V3、DeepSeek-R1 系列模型