GreatSQL社区

搜索

[已解决] mgr单主模式,主库切换后gtid的问题

786 7 2022-9-21 14:35
本帖最后由 李努力 于 2022-9-21 14:41 编辑

单主模式:

mgr1  primary
mgr2 secondary
mgr3 secondary
此时在测试库模拟主库宕机,在mgr1实例上执行:shutdown。
mgr2成为了新的主库,在该新主库上执行了两条dml语句。
此时启动mgr1执行:change...;start group_replication;发现加入组失败:
mgr1上报错如下:

此时在新主库上,show master status看到产生了1000003-1000005这样的gtid。

此时在新主库(mgr2)上执行了一条dml,1-11变成了1-12,而没有接着1000003-1000005进行变化。

想知道这个1000003-1000005是怎么产生的?并且mgr1启动后重新加入组复制,是不是因为1-11:1000003-1000005中间有空洞导致加入失败的?这种情况该怎么处理呢?
全部回复(7)
yejr 2022-9-21 15:07:43
两个补充问题:
1. 在mgr1实例上执行:shutdown。
===
是对MySQL执行shutdown,还是对OS执行shutdown?

2.启动mgr1执行:change...;start group_replication;
===
执行什么change?曾经是mgr成员的话,直接启动即可,无需再执行什么change。
李努力 2022-9-21 15:12:43
yejr 发表于 2022-9-21 15:07
两个补充问题:
1. 在mgr1实例上执行:shutdown。
===

1、对实例进行shutdown
2、开始是直接start的,同样的报错,后来又执行了一遍change master to master_user='repl',master_password='123456' for channel 'group_replication_recovery';
不知道为什么会产生1000003-1000005这样的gtid
李努力 2022-9-21 15:13:24
李努力 发表于 2022-9-21 15:12
1、对实例进行shutdown
2、开始是直接start的,同样的报错,后来又执行了一遍change master to master_us ...

版本是mysql8.0.21
yejr 2022-9-21 15:26:03

1. 贴一下my.cnf。
2. 可以尝试换成GreatSQL 8.0.25-16试试看。
李努力 2022-9-21 15:31:42
yejr 发表于 2022-9-21 15:26
1. 贴一下my.cnf。
2. 可以尝试换成GreatSQL 8.0.25-16试试看。

[auto]
server_uuid = mysqlmgr1_8001
[mysqld]
user=mysql
port=8001
datadir=/data0/mysql/8001_test
socket=/tmp/mysql_8001.sock
#innodb_data_home_dir=/data0/mysql/8001_test
#innodb_log_group_home_dir=/data0/mysql/8001_test
#innodb_data_file_path=ibdata0:512M:autoextend
#innodb_log_files_in_group=3
innodb_buffer_pool_size = 256M
#innodb_log_file_size=512M
#innodb_log_buffer_size=64M
default_authentication_plugin=mysql_native_password
[mysqld8001]
#[mysqld]
basedir=/usr/local/mysql8
default_authentication_plugin=mysql_native_password
mysqld = /usr/local/mysql8/bin/mysqld
#mysqladmin = /usr/local/mysql8/bin/mysqladmin
innodb_data_home_dir=/data0/mysql/8001_test
innodb_log_group_home_dir=/data0/mysql/8001_test
server-id = 18001
user = mysql
port = 8001
character_set_server = utf8mb4
explicit_defaults_for_timestamp = 1
max_allowed_packet = 100M
open_files_limit = 10000
tmpdir = /data0/mysql/tmp
datadir = /data0/mysql/8001_test
socket = /tmp/mysql_8001.sock
interactive_timeout = 1800
wait_timeout = 3600
lock_wait_timeout = 1800
skip_name_resolve = 1
max_connections = 1024
max_user_connections = 9000
max_connect_errors = 10000000
table_open_cache = 4096
table_definition_cache = 4096
table_open_cache_instances = 64
read_buffer_size = 16M
read_rnd_buffer_size = 32M
sort_buffer_size = 32M
max_length_for_sort_data = 4096
tmp_table_size = 64M
max_heap_table_size = 64M
join_buffer_size = 128M
thread_cache_size = 64
log_error = error.log
log_bin = binlog
#skip-log_bin
log_error_verbosity = 2
general_log_file = general.log
slow_query_log = 1
slow_query_log_file = slow.log
log_queries_not_using_indexes = 1
log_slow_admin_statements = 1
log_slow_slave_statements = 1
log_throttle_queries_not_using_indexes = 10
long_query_time = 2
min_examined_row_limit = 100
log-bin-trust-function-creators = 1
log-slave-updates = 1
innodb_page_size = 16384
innodb_buffer_pool_size = 256M
innodb_buffer_pool_instances = 16
innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
innodb_lru_scan_depth = 4096
innodb_lock_wait_timeout = 5
innodb_io_capacity = 10000
innodb_io_capacity_max = 20000
innodb_flush_method = O_DIRECT
#innodb_undo_logs = 128
#innodb_undo_tablespaces = 3
innodb_flush_neighbors = 0
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M
innodb_purge_threads = 4
#innodb_large_prefix = 1
innodb_thread_concurrency = 64
innodb_print_all_deadlocks = 1
innodb_strict_mode = 1
innodb_sort_buffer_size = 64M
innodb_write_io_threads = 16
innodb_read_io_threads = 16
innodb_file_per_table = 1
innodb_stats_persistent_sample_pages = 64
innodb_autoinc_lock_mode = 2
innodb_online_alter_log_max_size = 1G
innodb_open_files = 4096
loose_innodb_numa_interleave = 1
innodb_buffer_pool_dump_pct = 40
innodb_page_cleaners = 16
innodb_undo_log_truncate = 1
innodb_max_undo_log_size = 2G
innodb_purge_rseg_truncate_frequency = 128
master_info_repository = TABLE
relay_log_info_repository = TABLE
sync_binlog = 1
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates
binlog_format = ROW
binlog_rows_query_log_events = 1
binlog_expire_logs_seconds = 15
relay_log = relay.log
relay_log_recovery = 1
slave_skip_errors = ddl_exist_errors
slave-rows-search-algorithms = 'INDEX_SCAN,HASH_SCAN'
#report_host =
#report_port = 8001
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 16
slave_preserve_commit_order = 1
slave_transaction_retries = 128
binlog_gtid_simple_recovery = 1
performance-schema-instrument='memory/%=COUNTED'
performance_schema_digests_size = 40000
performance_schema_max_table_instances = 40000
performance_schema_max_sql_text_length = 4096
transaction_isolation = REPEATABLE-READ
log_timestamps = system
#show_compatibility_56 = on
report_host='10.222.11.11'
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
binlog_checksum=none;
master_info_repository='table';
relay_log_info_repository='table';
transaction_write_set_extraction=XXHASH64;
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa";
group_replication_start_on_boot=off;
group_replication_local_address="10.222.11.11:80011";
group_replication_group_seeds="10.222.11.11:80011,10.222.11.12:80011,10.222.11.13:80011";
group_replication_bootstrap_group=off;

yejr 2022-9-21 17:04:48
李努力 发表于 2022-9-21 15:12
1、对实例进行shutdown
2、开始是直接start的,同样的报错,后来又执行了一遍change master to master_us ...

1、对实例进行shutdown
===
是MySQL里执行shutdown?还是OS层执行kill -9?
前者的话,MGR应该会把事务广播出去,按理不应该会有问题。如果确认这样还是会报错的话,可以去MySQL官网报告bug了。
李努力 2022-9-21 17:14:28
yejr 发表于 2022-9-21 17:04
1、对实例进行shutdown
===
是MySQL里执行shutdown?还是OS层执行kill -9?

多谢老师,用的第一种情况,我再把流程再过一遍看看
李努力

4

主题

7

博客

190

贡献

中级会员

Rank: 3Rank: 3

积分
223

2022年度博学人物2022年度求知人物2022年度妙笔生花2022年度活跃用户助人为乐(铜)

合作电话:010-64087828

社区邮箱:greatsql@greatdb.com

社区公众号
社区小助手
QQ群
GMT+8, 2024-11-24 08:08 , Processed in 0.061921 second(s), 20 queries , Redis On.
快速回复 返回顶部 返回列表