MySQL组复制如何重置_Mysql组复制故障恢复测试

最新推荐文章于 2023-06-06 13:01:03 发布
最新推荐文章于 2023-06-06 13:01:03 发布
阅读量912 收藏 2
点赞数
文章标签： MySQL组复制如何重置
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_34237703/article/details/113519777
版权
本文演示了MySQL组复制所有成员服务器宕机重启后的恢复过程。首先，第一台MySQL实例设置group_replication_bootstrap_group为ON，启动组复制，再设置为OFF。接着，其他实例依次启动组复制。在模拟master宕机的场景中，组复制能够自动选择新的主节点并继续数据同步。当原master恢复后，能自动同步数据，恢复组复制状态。测试表明，只要有1台主机存活，组复制结构就能保持服务可用。
摘要由CSDN通过智能技术生成

在前面的两篇文章中，介绍了mysql组复制的特点及配置过程，本文演示mysql单组复制下的模拟故障测试。

一、组复制所有成员服务器宕机重启后的恢复

连接所有的mysql实例查询当前的组复制成员情况，状态都是OFFLINE，这种情况下如何恢复组复制？mysql> select * from performance_schema.replication_group_members;

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

| CHANNEL_NAME              | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

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

| group_replication_applier |           |             |        NULL | OFFLINE      |

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

1 row in set (0.00 sec)

在第一台mysql实例上将group_replication_bootstrap_group设置为ON，然后开启组复制，完成后再设置group_replication_bootstrap_group参数为OFFmysql> set global group_replication_bootstrap_group=ON;

Query OK, 0 rows affected (0.01 sec)

mysql> start group_replication;

Query OK, 0 rows affected (2.19 sec)

mysql> set global group_replication_bootstrap_group=OFF;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from performance_schema.replication_group_members;

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

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

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

| group_replication_applier | 8b643791-6d30-11e7-986a-000c29d53b31 | vm1         |        3306 | ONLINE       |

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

1 row in set (0.00 sec)

d8eb84a589cdedb84fe8c302fed1b778.png

第二台mysql实例上开启组复制mysql> select * from performance_schema.replication_group_members;

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

| CHANNEL_NAME              | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

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

| group_replication_applier |           |             |        NULL | OFFLINE      |

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

1 row in set (0.00 sec)

mysql> change master to master_user='repl',master_password='123456' for channel 'group_replication_recovery';

Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start group_replication;

Query OK, 0 rows affected (6.76 sec)

mysql> select * from performance_schema.replication_group_members;

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

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

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

| group_replication_applier | 35c331eb-6d3d-11e7-91e3-000c29e07281 | vm2         |        3306 | ONLINE       |

| group_replication_applier | 941bce76-6d40-11e7-b2fe-000c2909332c | vm3         |        3306 | ONLINE       |

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

2 rows in set (0.00 sec)

95a1e39d8a7dcc534ed92fbb2e3bd381.png

在第三台mysql实例开启组复制mysql> change master to master_user='repl',master_password='123456' for channel 'group_replication_recovery';

Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start group_replication;

Query OK, 0 rows affected (3.39 sec)

mysql> select * from performance_schema.replication_group_members;

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

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

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

| group_replication_applier | 35c331eb-6d3d-11e7-91e3-000c29e07281 | vm2         |        3306 | ONLINE       |

| group_replication_applier | 8b643791-6d30-11e7-986a-000c29d53b31 | vm1         |        3306 | ONLINE       |

| group_replication_applier | 941bce76-6d40-11e7-b2fe-000c2909332c | vm3         |        3306 | ONLINE       |

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

3 rows in set (0.00 sec)

3cf99a5d90349cc2c6635bfd8adfa3da.png

一般来说，第一台启动group replication的为组复制中的master角色，我们可以使用如下的SQL进行确认SELECT

*

FROM

PERFORMANCE_SCHEMA .replication_group_members

WHERE

member_id = (

SELECT

variable_value

FROM

PERFORMANCE_SCHEMA .global_status

WHERE

VARIABLE_NAME = 'group_replication_primary_member'

);

二、如果master宕机，组复制会如何？下面我们来测试一下

首先确认当前的master主机是VM2

70815218f9e8e809e50a03e2b0efa50f.png

[root@vm2 ~]# service mysqld stop

Shutting down MySQL............. SUCCESS![root@vm2 ~]# tail -f /mydata/vm2.err

2017-10-27T15:42:19.×××27Z 0 [Note] Giving 7 client threads a chance to die gracefully

2017-10-27T15:42:19.999375Z 0 [Note] Shutting down slave threads

2017-10-27T15:42:22.000341Z 0 [Note] Forcefully disconnecting 7 remaining clients

2017-10-27T15:42:22.000556Z 0 [Note] Plugin group_replication reported: 'Going to wait for view modification'

2017-10-27T15:42:22.002961Z 0 [Note] Plugin group_replication reported: 'getstart group_id 4317e324'

2017-10-27T15:42:25.462993Z 0 [Note] Plugin group_replication reported: 'state 4345 action xa_terminate'

2017-10-27T15:42:25.463472Z 0 [Note] Plugin group_replication reported: 'new state x_start'

2017-10-27T15:42:25.463514Z 0 [Note] Plugin group_replication reported: 'state 4272 action xa_exit'

2017-10-27T15:42:25.463650Z 0 [Note] Plugin group_replication reported: 'Exiting xcom thread'

2017-10-27T15:42:25.463675Z 0 [Note] Plugin group_replication reported: 'new state x_start'

2017-10-27T15:42:30.555581Z 0 [Note] Plugin group_replication reported: 'auto_increment_increment is reset to 1'

2017-10-27T15:42:30.555639Z 0 [Note] Plugin group_replication reported: 'auto_increment_offset is reset to 1'

2017-10-27T15:42:30.556496Z 19 [Note] Error reading relay log event for channel 'group_replication_applier': slave SQL thread was killed

2017-10-27T15:42:30.564277Z 16 [Note] Plugin group_replication reported: 'The group replication applier thread was killed'

2017-10-27T15:42:30.565453Z 0 [Note] Event Scheduler: Purging the queue. 0 events

2017-10-27T15:42:30.613823Z 0 [Note] Binlog end

2017-10-27T15:42:30.619483Z 0 [Note] Shutting down plugin 'group_replication'

2017-10-27T15:42:30.619582Z 0 [Note] Plugin group_replication reported: 'All Group Replication server observers have been successfully unregistered'

2017-10-27T15:42:30.620753Z 0 [Note] Shutting down plugin 'ngram'

2017-10-27T15:42:30.620801Z 0 [Note] Shutting down plugin 'BLACKHOLE'

2017-10-27T15:42:30.620820Z 0 [Note] Shutting down plugin 'ARCHIVE'

2017-10-27T15:42:30.620832Z 0 [Note] Shutting down plugin 'partition'

2017-10-27T15:42:30.620841Z 0 [Note] Shutting down plugin 'INNODB_SYS_VIRTUAL'

2017-10-27T15:42:30.620853Z 0 [Note] Shutting down plugin 'INNODB_SYS_DATAFILES'

2017-10-27T15:42:30.620937Z 0 [Note] Shutting down plugin 'INNODB_SYS_TABLESPACES'

2017-10-27T15:42:30.620946Z 0 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN_COLS'

2017-10-27T15:42:30.620951Z 0 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN'

2017-10-27T15:42:30.620957Z 0 [Note] Shutting down plugin 'INNODB_SYS_FIELDS'

2017-10-27T15:42:30.620961Z 0 [Note] Shutting down plugin 'INNODB_SYS_COLUMNS'

2017-10-27T15:42:30.620966Z 0 [Note] Shutting down plugin 'INNODB_SYS_INDEXES'

2017-10-27T15:42:30.620971Z 0 [Note] Shutting down plugin 'INNODB_SYS_TABLESTATS'

2017-10-27T15:42:30.620976Z 0 [Note] Shutting down plugin 'INNODB_SYS_TABLES'

2017-10-27T15:42:30.620980Z 0 [Note] Shutting down plugin 'INNODB_FT_INDEX_TABLE'

2017-10-27T15:42:30.620985Z 0 [Note] Shutting down plugin 'INNODB_FT_INDEX_CACHE'

2017-10-27T15:42:30.620990Z 0 [Note] Shutting down plugin 'INNODB_FT_CONFIG'

2017-10-27T15:42:30.620994Z 0 [Note] Shutting down plugin 'INNODB_FT_BEING_DELETED'

2017-10-27T15:42:30.620999Z 0 [Note] Shutting down plugin 'INNODB_FT_DELETED'

2017-10-27T15:42:30.621003Z 0 [Note] Shutting down plugin 'INNODB_FT_DEFAULT_STOPWORD'

2017-10-27T15:42:30.621008Z 0 [Note] Shutting down plugin 'INNODB_METRICS'

2017-10-27T15:42:30.621013Z 0 [Note] Shutting down plugin 'INNODB_TEMP_TABLE_INFO'

2017-10-27T15:42:30.621017Z 0 [Note] Shutting down plugin 'INNODB_BUFFER_POOL_STATS'

2017-10-27T15:42:30.621022Z 0 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE_LRU'

2017-10-27T15:42:30.621027Z 0 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE'

2017-10-27T15:42:30.621032Z 0 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX_RESET'

2017-10-27T15:42:30.621042Z 0 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX'

2017-10-27T15:42:30.621051Z 0 [Note] Shutting down plugin 'INNODB_CMPMEM_RESET'

2017-10-27T15:42:30.621056Z 0 [Note] Shutting down plugin 'INNODB_CMPMEM'

2017-10-27T15:42:30.621061Z 0 [Note] Shutting down plugin 'INNODB_CMP_RESET'

2017-10-27T15:42:30.621066Z 0 [Note] Shutting down plugin 'INNODB_CMP'

2017-10-27T15:42:30.621071Z 0 [Note] Shutting down plugin 'INNODB_LOCK_WAITS'

2017-10-27T15:42:30.621076Z 0 [Note] Shutting down plugin 'INNODB_LOCKS'

2017-10-27T15:42:30.621081Z 0 [Note] Shutting down plugin 'INNODB_TRX'

2017-10-27T15:42:30.621085Z 0 [Note] Shutting down plugin 'InnoDB'

2017-10-27T15:42:30.621309Z 0 [Note] InnoDB: FTS optimize thread exiting.

2017-10-27T15:42:30.622401Z 0 [Note] InnoDB: Starting shutdown...

2017-10-27T15:42:30.723215Z 0 [Note] InnoDB: Dumping buffer pool(s) to /mydata/ib_buffer_pool

2017-10-27T15:42:30.723542Z 0 [Note] InnoDB: Buffer pool(s) dump completed at 171027 11:42:30

2017-10-27T15:42:32.472064Z 0 [Note] InnoDB: Shutdown completed; log sequence number 2767811

2017-10-27T15:42:32.474350Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"

2017-10-27T15:42:32.474373Z 0 [Note] Shutting down plugin 'MEMORY'

2017-10-27T15:42:32.474385Z 0 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'

2017-10-27T15:42:32.474419Z 0 [Note] Shutting down plugin 'MRG_MYISAM'

2017-10-27T15:42:32.474431Z 0 [Note] Shutting down plugin 'MyISAM'

2017-10-27T15:42:32.474459Z 0 [Note] Shutting down plugin 'CSV'

2017-10-27T15:42:32.474471Z 0 [Note] Shutting down plugin 'sha256_password'

2017-10-27T15:42:32.474481Z 0 [Note] Shutting down plugin 'mysql_native_password'

2017-10-27T15:42:32.475429Z 0 [Note] Shutting down plugin 'binlog'

2017-10-27T15:42:32.477356Z 0 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

vm1主机的日志[root@vm1 ~]# tail -f /mydata/vm1.err

2017-10-27T15:42:22.634326Z 0 [Note] Plugin group_replication reported: 'getstart group_id 4317e324'

2017-10-27T15:42:23.095198Z 0 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

2017-10-27T15:42:23.095627Z 0 [Note] Plugin group_replication reported: 'Unsetting super_read_only.'

2017-10-27T15:42:23.095987Z 5 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

vm3主机的日志[root@vm3 ~]# tail -f /mydata/vm3.err

2017-10-27T15:42:22.235922Z 0 [Note] Plugin group_replication reported: 'getstart group_id 4317e324'

2017-10-27T15:42:22.696811Z 0 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

2017-10-27T15:42:22.697087Z 0 [Note] Plugin group_replication reported: 'Setting super_read_only.'

2017-10-27T15:42:22.697303Z 5 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

可以看到这个时候VM1自动提升为主了，且写入的数据可以继续同步到vm3，vm3的角色为slave,不能写入数据mysql> use yang

Database changed

mysql> insert into t1 values (2,'two');

Query OK, 1 row affected (0.03 sec)

mysql> select * from t1;

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

| id | name |

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

|  1 | one  |

|  2 | two  |

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

2 rows in set (0.00 sec)

10198afd204f60f0f4af74e658b2022f.png

mysql> select * from yang.t1;

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

| id | name |

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

|  1 | one  |

|  2 | two  |

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

2 rows in set (0.00 sec)

mysql> insert into yang.t1 values (3,'three');

ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

0ac537fcd492da07b0564ae2161005f7.png

如果此时vm1也跪了会如何呢？[root@vm1 ~]# service mysqld stop

Shutting down MySQL............. SUCCESS!

观察vm3的日志[root@vm3 ~]# tail -f /mydata/vm3.err

2017-10-27T15:42:22.235922Z 0 [Note] Plugin group_replication reported: 'getstart group_id 4317e324'

2017-10-27T15:42:22.696811Z 0 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

2017-10-27T15:42:22.697087Z 0 [Note] Plugin group_replication reported: 'Setting super_read_only.'

2017-10-27T15:42:22.697303Z 5 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

2017-10-27T15:46:54.618998Z 5 [Note] Plugin group_replication reported: 'Primary had applied all relay logs, disabled conflict detection'

2017-10-27T15:49:57.546061Z 0 [Note] Plugin group_replication reported: 'getstart group_id 4317e324'

2017-10-27T15:49:58.612942Z 0 [Note] Plugin group_replication reported: 'Unsetting super_read_only.'

2017-10-27T15:49:58.613092Z 5 [Note] Plugin group_replication reported: 'A new primary was elected, enabled conflict detection until the new primary applies all relay logs'

VM3写入测试mysql> select * from performance_schema.replication_group_members;

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

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

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

| group_replication_applier | 941bce76-6d40-11e7-b2fe-000c2909332c | vm3         |        3306 | ONLINE       |

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

1 row in set (0.00 sec)

mysql> insert into yang.t1 values (3,'three');

Query OK, 1 row affected (0.02 sec)

mysql> select * from yang.t1;

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

| id | name  |

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

|  1 | one   |

|  2 | two   |

|  3 | three |

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

3 rows in set (0.00 sec)

f90c0478bad93465b205f830d49d86d1.png

三、将VM1和VM2恢复后会如何？我们来测试一下

847b4dd9d7bef7a2ffe113084024e519.png

9aee603adf4a2e64382d342a7d37ed79.png

在最早宕机VM2查询数据是否正常

ee250b2ced91dcae23e92174d923cf3a.png

四、总结

通过上述简单的测试，发现mysql的组复制还是挺好用的，3台mysql实例组成的组复制结构下，只要有1台主机存活，整个mysql服务就可用，在故障主机恢复之后，组复制会自动同步数据，恢复组复制状态。

但在实际的使用过程中，需要考虑到客户端或者数据库中间件的连接问题。因为在单组复制模式下，slave是自读的，所有的写入请求都通过master，如果master宕机，程序或者客户端、数据库中间件读写分离的连接如何平滑处理？

萌萌的微微哟
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
简述mysql监控组复制
09-08
【MySQL 监控组复制】是MySQL高可用性与容错性的重要特性，它允许数据库集群中的多个服务器间实现数据的实时同步，确保在单个服务器出现故障时，整个系统仍能正常运行。监控组复制主要是通过对集群内各成员的状态...
Mysql 5.7 基于组复制(MySQL Group Replication) - 精华版
01-17
"MySQL 5.7 基于组复制(MySQL Group Replication)" 本篇文章详细介绍了 MySQL 5.7 基于组复制(MySQL Group Replication)的配置说明，实为线上操作手册，在此分享，希望能帮助到有用到的朋友～ MySQL 组复制(MySQL...
mysql replication writing to net_Mysql组复制：永远停留在RECOVERING上
weixin_32247165的博客
01-27 600
2018-06-11T09:22:57.490896Z 0 [Warning] option ‘max_allowed_packet’:unsigned value 3221225472 adjusted to 10737418242018-06-11T09:22:57.490942Z 0 [Warning] The use of InnoDB is mandatorysince MySQL 5....
mysql组复制 多数server异常后重新配置集群
敖尔其楞的专栏
09-19 779
在组复制中，如果集群中的大部分处于异常状态，不可达，那么集群会停止处理请求，组复制可以让你通过一个特殊的配置重新设置组成员，比如在一个5节点的集群中，3个异常宕掉，2个在线。你可以强制做一个只包含s1,s2的成员的重新配置。需要做的额是检查对方的地址，在s1,s2上使用下面的命令 SELECT @@group_replication_local_address; 在获取了上面的配置信息后，使用
mysql组复制自动离线_新特性解读 | 组复制成员的自动保护模式
weixin_33594662的博客
01-19 152
原文：https://mysqlhighavailability...作者：Nuno Carvalho 翻译：管长龙Nuno Carvalho 是 Oracle 的首席软件工程师和 MySQL 复制服务团队负责人，该团队负责 MySQL 组复制插件。他的研究兴趣包括复制技术，可靠的系统和高可用性。在加入 MySQL 团队之前，他是葡萄牙米尼奥大学的研究生和研究员，在那里他设计和实现了改善分布式系统...
mysql 5.7 group replication 之七 [ERROR] [MY-011735] [Repl] Plugin group_replication reported
一名数据库爱好者的专栏
07-03 4614
os: centos 7.4.1708 db: mysql 8.0.20 标题写的是 mysql 5.7，实际使用的是 mysql 8 ip规划入下 192.168.56.61 node1 192.168.56.62 node2 192.168.56.63 node3 版本 # cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) # # # yum list installed |grep -i mysql80 mysql
mysql 5.7 Group Replication
aecuhty88306453的博客
01-06 201
MySQL 组复制实现了基于复制协议的多主更新(单主模式)。 复制组由多个 server成员构成，并且组中的每个 server 成员可以独立地执行事务。但所有读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不需要在冲突检测，可以立即提交。 对于任何 RW 事务，提交操作并不是由始发 server 单向决定的，而是由组来决定是否提交。准确地说，在始发 ser...
MySQL 组复制研究pdf
最新发布
09-19
这使得MySQL Group Replication特别适合那些需要零数据丢失（0 RPO，Recovery Point Objective）和快速故障恢复的场景。 MySQL Shell（或称AdminAPI）是一个强大的管理工具，可以通过它轻松地创建、管理和监控...
Mysql Group Replication
junqing124的专栏
08-20 837
主要安装方法在https://dev.mysql.com/doc/refman/5.7/en/group-replication-getting-started.html 碰到的异常有:Plugin group_replication reported: 'This member has more executed transactions than those present in the
mysql 8.0 MRG
net.wei的博客
04-20 506
MRG部署 1.首先对部署的节点配置好hosts文件,如下 172.16.227.157 weisir01 172.16.227.158 weisir02 172.16.227.159 weisir03 2.关掉防火墙，一定切记 3.配置资源准备 ip port role 备注 172.16.227.157 3311 主节点（primary） 端口对外提供数据请求 172.16.227.157 3301 端口作为集群通信端口 172.16.227.158 3312 从节点（seco
查看复制同步情况
风格的BLOG
09-09 1178
用这个存储过程查看复制的同步情况,默认参数快速查看是否同步: --在分发服务器的分发数据库上执行if object_id(sp_repl_syn) is not null drop procedure sp_repl_syn GOcreate procedure sp_repl_syn @publication sysname=% --模糊查询,发布名
Mysql的全同步复制（组复制）
qq_46089299的博客
05-12 934
二、搭建实验环境 实验环境：（一主多从模式），一个master节点+两个slave节点 主机名 IP 功能 server1 172.25.254.1 master节点 server2 172.25.254.2 slave节点 server3 172.25.254.3 slave节点 三、开始实现组复制（全同步）的操作流程 组复制（全同步复制）互相为master和slave；相当于一个集群，都可以作为master和slave
MySQL报错：The server quit without updating PID file 我的解决思路和方法
热门推荐
m0_59308369的博客
09-15 3万+
Starting MySQL. ERROR! The server quit without updating PID file Can't connect to local MySQL server through socket '/tmp/mysql.sock'的解决方法和思路
mysql下载是port报错_mysql group replication添加复制节点报错
weixin_30794381的博客
02-04 206
该楼层疑似违规已被系统折叠隐藏此楼查看此楼恳求各位大神给把把脉，到底问题处在那个环节环境： 三台物理机 192.168.1.3 192.168.1.4 192.168.1.5配置文件：[mysqld]basedir=/usr/local/mysqldatadir=/var/lib/mysqlserver_id=1port=3306socket=/var/run/mysqld/mysql.sock...
mysql 被关闭了_mysql被关闭简析
weixin_42467411的博客
02-18 858
mysql被关闭简析发布时间：2020-04-29 15:53:41来源：亿速云阅读：148作者：亿速云本文主要给大家介绍mysql被关闭简析，文章内容都是笔者用心摘选和编辑的，具有一定的针对性，对大家的参考意义还是比较大的，下面跟笔者一起了解下主题内容吧。2019-06-13T02:33:01.664701Z 0 [Note] Giving 21 client threads a chance ...
MGR 问题处理
chenglong411的博客
06-06 584
将my.cnf中的参数group_replication_group_seeds设置为只包含除自身外其他group成员的ip地址以及内部通信端口，如果写成group所有成员的IP地址则会出现这个错误，这和相同网段的MGR部署方式有些差异。解决方案：有些成员有组内其它成员没有的事务，set global group_replication_allow_local_disjoint_gtids_join=ON;解决方法：配置group_replication_ip_whitelist。
mysql mgr节点无法连接,MySQL MGR成员故障处理
weixin_39897267的博客
03-17 2358
1. 主观造成主从节点间binlog的丢失MGR故障模拟1如下是搭建完成后的MGR集群，目前集群处于完全正常的状态中。#执行如下操作，主观造成主从节点间binlog的丢失use shooter;SET SQL_LOG_BIN=0; #设置下面操作不记录到binlog日志中INSERT INTO book VALUES (4, 'shooter');SET SQL_LOG_BIN=1; #开启记录...
[图文]搭建InnoDB Cluster详细流程
2201_75287294的博客
11-19 1070
搭建InnoDB Cluster详细流程
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值