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

MySQL5.7 GTID 运维实战

2017-02-15 8619
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 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 版gtid
云数据库 RDS MySQL 版运维
mysql运维
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
兰春
目录
相关文章
请看我回答~
|
4天前
|
运维 应用服务中间件 持续交付
自动化运维的利器：Ansible实战应用
【9月更文挑战第33天】本文将带你深入理解Ansible，一个强大的自动化运维工具。我们将从基础概念开始，逐步探索其配置管理、任务调度等功能，并通过实际案例演示其在自动化部署和批量操作中的应用。文章旨在通过浅显易懂的语言和实例，为读者揭开Ansible的神秘面纱，展示其在简化运维工作中的强大能力。
请看我回答~
101 64
请看我回答~
|
13天前
|
运维 安全 应用服务中间件
自动化运维的利剑：Ansible实战应用
【9月更文挑战第24天】在现代IT基础设施的快速迭代与扩展中，自动化运维成为提升效率、保障稳定性的关键。本文将深入探讨Ansible这一流行的自动化工具，通过实际案例分析其如何简化日常运维任务，优化工作流程，并提高系统的可靠性和安全性。我们将从Ansible的基础概念入手，逐步深入到高级应用技巧，旨在为读者提供一套完整的Ansible应用解决方案。
请看我回答~
53 3
尹正杰
|
1月前
|
监控 关系型数据库 MySQL
zabbix agent集成percona监控MySQL的插件实战案例
这篇文章是关于如何使用Percona监控插件集成Zabbix agent来监控MySQL的实战案例。
尹正杰
32 2
zabbix agent集成percona监控MySQL的插件实战案例
我不是游客20240119
|
1月前
|
运维 监控 应用服务中间件
自动化运维的新篇章：Ansible Playbooks入门与实战
【9月更文挑战第1天】在追求效率和稳定性的今天，自动化运维已经成为IT行业的必修课。本文将带你走进自动化工具Ansible的世界，通过实战案例深入理解Ansible Playbooks的编写和应用。文章不仅介绍基础概念，更通过具体代码示例，展示如何利用Ansible简化日常运维任务，提升工作效率。无论你是运维新手还是希望深化自动化技能的资深人士，本指南都将为你开启一段新的学习旅程。
我不是游客20240119
52 4
请看我回答~
|
2月前
|
运维 安全 应用服务中间件
自动化运维的利器：Ansible入门与实战网络安全与信息安全：关于网络安全漏洞、加密技术、安全意识等方面的知识分享
【8月更文挑战第30天】在当今快速发展的IT时代，自动化运维已成为提升效率、减少错误的关键。本文将介绍Ansible，一种流行的自动化运维工具，通过简单易懂的语言和实际案例，带领读者从零开始掌握Ansible的使用。我们将一起探索如何利用Ansible简化日常的运维任务，实现快速部署和管理服务器，以及如何处理常见问题。无论你是运维新手还是希望提高工作效率的资深人士，这篇文章都将为你开启自动化运维的新篇章。
请看我回答~
43 5
请看我回答~
|
2月前
|
运维 Ubuntu 应用服务中间件
自动化运维的利器：Ansible入门与实战应用
【8月更文挑战第28天】在现代IT运维领域，自动化已成为提升效率、确保一致性和可靠性的关键。本文将引导读者了解Ansible——一种流行的自动化工具，它通过简化配置管理、部署和任务自动化流程，助力运维人员轻松应对日常挑战。从基础安装到高级用法，我们将一步步探索Ansible的魔力，并通过实际案例展示如何有效利用Ansible优化运维工作。无论你是初学者还是有经验的管理员，这篇文章都将为你提供宝贵的知识和技能，让你的运维之旅更加顺畅。
请看我回答~
32 1
Python大数据分析
|
2月前
|
SQL 关系型数据库 MySQL
干货！python与MySQL数据库的交互实战
干货！python与MySQL数据库的交互实战
Python大数据分析
53 1
william.zhang(张)
|
2月前
|
缓存 运维 Linux
深入解析：一步步掌握 CentOS 7 安装全流程及运维实战技巧
深入解析：一步步掌握 CentOS 7 安装全流程及运维实战技巧
william.zhang(张)
246 2
请看我回答~
|
2月前
|
运维 Linux Apache
自动化运维工具：Ansible入门与实战
【8月更文挑战第31天】 本文将引导读者理解自动化运维的重要性，并通过介绍Ansible这一强大的自动化工具，展示如何简化和加速IT管理任务。文章不仅讲解了Ansible的基础概念，还通过实例展示了如何配置和使用Ansible进行日常的运维工作，包括部署、配置管理和任务自动化等。无论你是运维新手还是希望提高现有工作流程的效率，这篇文章都会为你提供实用的知识和技能。
请看我回答~
33 0
请看我回答~
|
2月前
|
运维 Devops 应用服务中间件
自动化运维工具：Ansible的实战应用
【8月更文挑战第24天】在现代IT运维管理中，自动化已成为提升效率、减少错误的关键。本文将深入探讨Ansible，一款流行的自动化运维工具，通过实际案例展示其在配置管理、任务执行等方面的应用。我们将从Ansible的基础架构出发，逐步解析其模块和插件的使用，以及如何构建Playbooks来自动化日常任务。文章不仅提供代码示例，还着重讨论了Ansible在实际工作中的最佳实践和问题解决策略，旨在帮助读者更好地理解和运用Ansible，以实现运维工作的高效和自动化。
请看我回答~
50 0

热门文章

最新文章

  • 1
    高效运维之Docker持续部署图文详解
  • 2
    【运维知识进阶篇】一篇文章带你搞懂Jumperserver（保姆级教程：安装+用户与用户组+创建资产+授权资产+创建数据库+sudo提权+命令过滤+多因子认证+网域功能+审计台）（一）
  • 3
    理性运维 综合管控
  • 4
    linux云自动化运维基础知识9（进程）
  • 5
    CrazyWing：Python自动化运维开发实战 九、Python数据类型之列表
  • 6
    学python 对以后运维的工作很重要吗
  • 7
    ClusterShell之自动化运维工具
  • 8
    IT运维服务商如何将WannaCry拒之门外？恒远志成称安全需防微杜渐
  • 9
    2016全新Linux+Python高端运维班-Linux服务 DNS，httpd，加密通讯，vsftp，NFS，samba服务练习
  • 10
    系统批量运维管理器Fabric详解
  • 1
    为什么MySQL分页查询偏移量越大查询越慢
    213
  • 2
    MySQL的锁机制
    51
  • 3
    【Mysql】在多表查询过程中如果已经起了别名，就不能通过表名限定字段
    67
  • 4
    【MySQL-11】多表查询全解-【多表关系/内外自连接/子查询/多表查询案例链接】（可cv代码＆案例演示）
    87
  • 5
    【Mysql-12】一文解读【事务】-【基本操作/四大特性/并发事务问题/事务隔离级别】
    73
  • 6
    【MySQL-10】数据库函数-案例演示【字符串/数值/日期/流程控制函数】（代码演示＆可cv代码）
    443
  • 7
    【MySQL-10】DCL-数据控制语言-【管理用户＆权限控制】 （语法语句＆案例演示＆可cv案例代码）
    51
  • 8
    【MySQL-9】一文带你搞定 外键约束＆其【更新/删除行为】（可cv代码＆案例演示）
    165
  • 9
    【MySQL】DQL-案例练习-DQL基本介绍＆语法＆执行顺序（代码演示）
    52
  • 10
    【MySQL】DQL-排序查询-语法＆注意事项＆可cv例题语句
    52

    • 相关课程

    更多
  • 企业运维之弹性计算原理与实践
  • 企业运维之云上网络原理与实践课程
  • 企业级运维之云原生与Kubernetes实战课程
  • 面向运维的 python 脚本速成-1024程序员节创造营公益课
  • Linux企业运维实战 - 入门及常用命令
  • 玩转云上智能运维

    • 相关电子书

    更多
  • 企业运维之云原生和Kubernetes 实战
  • 可视化架构运维实践
  • 2021云上架构与运维峰会演讲合集

    • 相关实验场景

    更多
  • MySQL基础-学生管理系统数据库设计
  • MyBase MySQL实例资源灵活弹配
  • 如何开通MySQL的专属集群
  • 云端MySQL的安装及应用
  • 体验PolarDB MySQL多主集群
  • 快速开发光伏电站数字孪生运维系统

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    阿里云对象存储OSS怎么收费？包年包月和按量付费价格表