GreatSQL MGR三节点基于时间点恢复

GreatSQL MGR优化参考 前言 GreatSQL运行更平稳,不会有大的抖动。MySQL官方版本的MGR更适合在中小规模业务环境下运行。 1. GreatSQL的优势 GreatSQL的优势在于提升了MGR的性能及可靠性,及修复了众多bug。主要有以下几点: 提升大事务并发性能及稳定性 优化MGR队列garbage collect机制、改进流控算法,以及减少每次发送数据量,避免性能抖动 解决了AFTER模式下,存在节点加入集群时容易出错的问题 在 AFTER模式下,强一致性采用多数派原则,以适应网络分区的场景 当MGR节点崩溃时,能 阅读详情

GreatSQL MGR三节点基于时间点恢复

前言

本文将介绍DDL模拟误操作数据库后,怎么恢复到误操作时间点?

解决方案:利用binlog伪装master实例(搭建伪主从复制环境),让复制应用binlog停留在具体时间点对应的gtid上。

方案可以帮助客户在发生DDL事故时快速恢复数据到误操作之前,避免进一步的损失。

文章分为三个阶段:

  1. 自行准备一套GreatSQL MGR三节点集群环境
  2. 使用clone提前物理备份一次用来后面恢复使用,集群需要准备测试数据使用sysbench造数据,然后对数据库误操作DDL,再备份走binlog文件用于伪装master。
  3. 数据恢复到误操作DDL具体时间点对应的gtid上。

MGR组复制三节点环境介绍

hostnameipportroleversion
zhangbei-node1192.168.56.2213001primaryGreatSQL-8.0.32-27
zhangbei-node2192.168.56.993001secondaryGreatSQL-8.0.32-27
zhangbei-node3192.168.56.63001secondaryGreatSQL-8.0.32-27

准备好MGR三节点集群

以下是GreatSQL MGR三节点集群结构信息

greatsql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | a4eadfd5-408e-11f0-abe0-00163ecf1759 | 192.168.56.221 |        3001 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
| group_replication_applier | a8f6d0b9-408e-11f0-ac0f-00163ecf10b8 | 192.168.56.99  |        3001 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
| group_replication_applier | a91ddcd1-408e-11f0-8ff1-00163efe4d00 | 192.168.56.6   |        3001 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

创建testdb数据库,用于后面sysbench读写

greatsql> CREATE DATABASE testdb;
Query OK, 1 row affected (0.01 sec)

Clone备份数据库实例

以下是clone备份MGR主节点 192.168.56.221:3001 实例到本地,用于后面临时恢复出集群的一个基础实例。

$ mkdir -p /backup
$ chown greatsql:greatsql /backup

$ /usr/local/greatsql/bin/mysqld -S /tmp/greatsql3001.sock

greatsql> CLONE LOCAL DATA DIRECTORY='/backup/paxos3001';
Query OK, 0 rows affected (6.86 sec)

$ ll /backup/paxos3001/
total 1107340
drwxr-x--- 2 greatsql greatsql       4096 Jun 17 00:53 #clone
-rw-r----- 1 greatsql greatsql       6289 Jun 17 00:53 ib_buffer_pool
-rw-r----- 1 greatsql greatsql 1073741824 Jun 17 00:53 ibdata1
drwxr-x--- 2 greatsql greatsql       4096 Jun 17 00:53 #innodb_redo
drwxr-x--- 2 greatsql greatsql       4096 Jun 17 00:53 mysql
-rw-r----- 1 greatsql greatsql   26214400 Jun 17 00:53 mysql.ibd
drwxr-x--- 2 greatsql greatsql       4096 Jun 17 00:53 sys
-rw-r----- 1 greatsql greatsql     376832 Jun 17 00:53 sys_mac.ibd
-rw-r----- 1 greatsql greatsql   16777216 Jun 17 00:53 undo_001
-rw-r----- 1 greatsql greatsql   16777216 Jun 17 00:53 undo_002

sysbench准备数据

向Primary节点的testdb数据库使用sysbench造一些数据,为了后续使用这部分测试数据误操作和恢复。

$ sysbench /usr/local/share/sysbench/oltp_read_write.lua \
>     --db-driver=mysql --mysql-host=192.168.56.221 --mysql-port=3001 --mysql-user=wanli --mysql-password=wanli \
>     --mysql-db=testdb --tables=8 --table-size=10000 --create-secondary=on --report-interval=1 \
>     --threads=8 --reconnect=0 --db-ps-mode=disable --skip_trx=off --events=2000000 --auto_inc=0 --time=600 \
>     --mysql-ignore-errors=6002,6004,4012,2013,4016,1062,8532,8530,8551,8516 prepare
sysbench 1.1.0-df89d34 (using bundled LuaJIT 2.1.0-beta3)

Initializing worker threads...

Creating table 'sbtest6'...Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest5'...
Creating table 'sbtest4'...

Creating table 'sbtest8'...
Creating table 'sbtest1'...
Creating table 'sbtest7'...
Inserting 10000 records into 'sbtest7'
Inserting 10000 records into 'sbtest6'
Inserting 10000 records into 'sbtest4'
Inserting 10000 records into 'sbtest5'
Inserting 10000 records into 'sbtest1'
Inserting 10000 records into 'sbtest3'
Inserting 10000 records into 'sbtest2'
Inserting 10000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest4'...
Creating a secondary index on 'sbtest8'...

误操作数据库

  1. 在sysbench继续run压测读写数据的模式下。
  2. 进行切割binog为了多产生一些binlog文件。
  3. 测试更新update埋点数据后,再删除testdb数据库,此时sysbench进程会报错终止。

sysbench继续压测中

$ sysbench /usr/local/share/sysbench/oltp_read_write.lua \
>     --db-driver=mysql --mysql-host=192.168.56.221 --mysql-port=3001 --mysql-user=wanli --mysql-password=wanli \
>     --mysql-db=testdb --tables=8 --table-size=10000 --create-secondary=on --report-interval=1 \
>     --threads=8 --reconnect=0 --db-ps-mode=disable --skip_trx=off --events=2000000 --auto_inc=0 --time=900 \
>     --mysql-ignore-errors=6002,6004,4012,2013,4016,1062,8532,8530,8551,8516 run
sysbench 1.1.0-df89d34 (using bundled LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 8
Report intermediate results every 1 second(s)
Initializing random number generator from current time


Initializing worker threads...

Threads started!

[ 1s ] thds: 8 tps: 511.40 qps: 10379.45 (r/w/o: 7271.20/2077.48/1030.77) lat (ms,95%): 23.95 err/s: 0.00 reconn/s: 0.00
[ 2s ] thds: 8 tps: 345.46 qps: 6775.94 (r/w/o: 4740.25/1349.78/685.90) lat (ms,95%): 20.74 err/s: 0.00 reconn/s: 0.00
[ 3s ] thds: 8 tps: 307.88 qps: 6290.62 (r/w/o: 4406.33/1263.52/620.77) lat (ms,95%): 22.28 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 8 tps: 310.02 qps: 6147.36 (r/w/o: 4309.25/1218.07/620.04) lat (ms,95%): 22.28 err/s: 0.00 reconn/s: 0.00
[ 5s ] thds: 8 tps: 284.11 qps: 5725.24 (r/w/o: 4008.57/1148.45/568.22) lat (ms,95%): 21.89 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 8 tps: 316.95 qps: 6239.03 (r/w/o: 4358.32/1246.81/633.90) lat (ms,95%): 18.95 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 8 tps: 312.99 qps: 6369.76 (r/w/o: 4460.83/1282.95/625.98) lat (ms,95%): 18.95 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 8 tps: 321.74 qps: 6363.85 (r/w/o: 4462.39/1260.98/640.48) lat (ms,95%): 19.65 err/s: 0.00 reconn/s: 0.00

切割binlog文件

greatsql> SHOW BINARY LOGS;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000003 |       193 | No        |
| mysql-bin.000004 |  87720660 | No        |
| mysql-bin.000005 |   7202697 | No        |
+------------------+-----------+-----------+
3 rows in set (0.00 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.06 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.01 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.01 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.01 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.02 sec)

greatsql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.01 sec)

greatsql> SHOW BINARY LOGS;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000003 |       193 | No        |
| mysql-bin.000004 |  87720660 | No        |
| mysql-bin.000005 |   9590028 | No        |
| mysql-bin.000006 |   2642522 | No        |
| mysql-bin.000007 |    735834 | No        |
| mysql-bin.000008 |   3114129 | No        |
| mysql-bin.000009 |   2595175 | No        |
| mysql-bin.000010 |   4431921 | No        |
| mysql-bin.000011 |   4323716 | No        |
| mysql-bin.000012 |  10490537 | No        |
| mysql-bin.000013 |   3813720 | No        |
| mysql-bin.000014 |   4515287 | No        |
| mysql-bin.000015 |   4463553 | No        |
| mysql-bin.000016 |   4255894 | No        |
| mysql-bin.000017 |   2667369 | No        |
| mysql-bin.000018 |   1873005 | No        |
+------------------+-----------+-----------+
16 rows in set (0.00 sec)

用update语句更新一条数据,来设置埋点数据

greatsql> USE testdb;
Database changed

greatsql> SELECT * FROM sbtest1 LIMIT 1;
+----+------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k    | c                                                                                                                       | pad                                                         |
+----+------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
|  1 | 6462 | 01827431929-96493593496-34123137724-20587427608-00689345478-40151015374-92698484513-00365713924-30181341062-76715092993 | 22195207048-70116052123-74140395089-76317954521-98694025897 |
+----+------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)

greatsql> SELECT now();begin;update sbtest1 SET c='wanli' WHERE id=1;commit;
+---------------------+
| now()               |
+---------------------+
| 2025-06-17 01:08:02 |
+---------------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Query OK, 0 rows affected (0.00 sec)

greatsql> SELECT now();
+---------------------+
| now()               |
+---------------------+
| 2025-06-17 01:08:08 |
+---------------------+
1 row in set (0.00 sec)

此时进行误操作。

greatsql> DROP DATABASE testdb;
Query OK, 8 rows affected (0.11 sec)

greatsql> SELECT now();
+---------------------+
| now()               |
+---------------------+
| 2025-06-17 01:08:22 |
+---------------------+
1 row in set (0.01 sec)

greatsql> SHOW BINARY LOGS;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000003 |       193 | No        |
| mysql-bin.000004 |  87720660 | No        |
| mysql-bin.000005 |   9590028 | No        |
| mysql-bin.000006 |   2642522 | No        |
| mysql-bin.000007 |    735834 | No        |
| mysql-bin.000008 |   3114129 | No        |
| mysql-bin.000009 |   2595175 | No        |
| mysql-bin.000010 |   4431921 | No        |
| mysql-bin.000011 |   4323716 | No        |
| mysql-bin.000012 |  10490537 | No        |
| mysql-bin.000013 |   3813720 | No        |
| mysql-bin.000014 |   4515287 | No        |
| mysql-bin.000015 |   4463553 | No        |
| mysql-bin.000016 |   4255894 | No        |
| mysql-bin.000017 |   2667369 | No        |
| mysql-bin.000018 | 163136954 | No        |
+------------------+-----------+-----------+
16 rows in set (0.00 sec)

在testdb库误操作被删除情况下,sysbench进程报错终止。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

现在需要恢复数据到时间点大概是误操作时间 2025-06-17 01:08:08 左右,在这个时间点左右来确认binlog文件。

备份binlog

现在备份主节点binlog

greatsql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | a4eadfd5-408e-11f0-abe0-00163ecf1759 | 192.168.56.221 |        3001 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
| group_replication_applier | a8f6d0b9-408e-11f0-ac0f-00163ecf10b8 | 192.168.56.99  |        3001 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
| group_replication_applier | a91ddcd1-408e-11f0-8ff1-00163efe4d00 | 192.168.56.6   |        3001 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

$ cd /data/paxos/paxos3001/logs/
$ ll -h mysql-bin.*
-rw-r----- 1 greatsql greatsql  193 Jun 17 00:36 mysql-bin.000003
-rw-r----- 1 greatsql greatsql  84M Jun 17 01:03 mysql-bin.000004
-rw-r----- 1 greatsql greatsql 9.2M Jun 17 01:03 mysql-bin.000005
-rw-r----- 1 greatsql greatsql 2.6M Jun 17 01:03 mysql-bin.000006
-rw-r----- 1 greatsql greatsql 719K Jun 17 01:03 mysql-bin.000007
-rw-r----- 1 greatsql greatsql 3.0M Jun 17 01:03 mysql-bin.000008
-rw-r----- 1 greatsql greatsql 2.5M Jun 17 01:03 mysql-bin.000009
-rw-r----- 1 greatsql greatsql 4.3M Jun 17 01:03 mysql-bin.000010
-rw-r----- 1 greatsql greatsql 4.2M Jun 17 01:04 mysql-bin.000011
-rw-r----- 1 greatsql greatsql  11M Jun 17 01:04 mysql-bin.000012
-rw-r----- 1 greatsql greatsql 3.7M Jun 17 01:04 mysql-bin.000013
-rw-r----- 1 greatsql greatsql 4.4M Jun 17 01:04 mysql-bin.000014
-rw-r----- 1 greatsql greatsql 4.3M Jun 17 01:04 mysql-bin.000015
-rw-r----- 1 greatsql greatsql 4.1M Jun 17 01:04 mysql-bin.000016
-rw-r----- 1 greatsql greatsql 2.6M Jun 17 01:04 mysql-bin.000017
-rw-r----- 1 greatsql greatsql 156M Jun 17 01:08 mysql-bin.000018
-rw-r----- 1 greatsql greatsql  704 Jun 17 01:04 mysql-bin.index

$ mkdir -p /backup/paxos-binlog
$ cp -a mysql-bin.* /backup/paxos-binlog/

$ ll /backup/paxos-binlog/
total 301316
-rw-r----- 1 greatsql greatsql       193 Jun 17 00:36 mysql-bin.000003
-rw-r----- 1 greatsql greatsql  87720660 Jun 17 01:03 mysql-bin.000004
-rw-r----- 1 greatsql greatsql   9590028 Jun 17 01:03 mysql-bin.000005
-rw-r----- 1 greatsql greatsql   2642522 Jun 17 01:03 mysql-bin.000006
-rw-r----- 1 greatsql greatsql    735834 Jun 17 01:03 mysql-bin.000007
-rw-r----- 1 greatsql greatsql   3114129 Jun 17 01:03 mysql-bin.000008
-rw-r----- 1 greatsql greatsql   2595175 Jun 17 01:03 mysql-bin.000009
-rw-r----- 1 greatsql greatsql   4431921 Jun 17 01:03 mysql-bin.000010
-rw-r----- 1 greatsql greatsql   4323716 Jun 17 01:04 mysql-bin.000011
-rw-r----- 1 greatsql greatsql  10490537 Jun 17 01:04 mysql-bin.000012
-rw-r----- 1 greatsql greatsql   3813720 Jun 17 01:04 mysql-bin.000013
-rw-r----- 1 greatsql greatsql   4515287 Jun 17 01:04 mysql-bin.000014
-rw-r----- 1 greatsql greatsql   4463553 Jun 17 01:04 mysql-bin.000015
-rw-r----- 1 greatsql greatsql   4255894 Jun 17 01:04 mysql-bin.000016
-rw-r----- 1 greatsql greatsql   2667369 Jun 17 01:04 mysql-bin.000017
-rw-r----- 1 greatsql greatsql 163136954 Jun 17 01:08 mysql-bin.000018
-rw-r----- 1 greatsql greatsql       704 Jun 17 01:04 mysql-bin.index

在此进行使用mysqlbinlog工具进行解析binlog文件,选择这个binlog文件属性时间和误操作时间相对应,所以是mysql-bin.000018,通过解析binlog文件,搜索 drop database 关键词,此时可以获取这个DDL误操作删除数据库的动作的gtid

$ /usr/local/greatsql/bin/mysqlbinlog --no-defaults /backup/paxos-binlog/mysql-bin.000018 |less

SET @@SESSION.GTID_NEXT= '3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:122961'/*!*/;

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

恢复到误操作删除数据库时间点之前

拉起之前克隆备份物理文件启动一个实例,端口为3002

$ cd /backup/paxos3001/
$ cat my.cnf
[mysqld]
port = 3002
socket = /tmp/greatsql3002.sock
mysqlx = OFF
lower_case_table_names = 1

$ /usr/local/greatsql/bin/mysqld_safe --defaults-file=./my.cnf --datadir=./ --user=greatsql &
[1] 6402
mysqld_safe Adding '/opt/greatsql/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64/lib/mysql/libjemalloc.so.1' to LD_PRELOAD for mysqld
Logging to './zhangbei-node1.err'.
2025-06-16T17:23:30.966273Z mysqld_safe Starting mysqld daemon with databases from .

登录
$ /usr/local/greatsql/bin/mysql -S /tmp/greatsql3002.sock
greatsql>

再准备一个数据库单机实例,端口为3003

$ mkdir -p /data/paxos/greatsql3003/{data,logs,tmp}
$ cp /data/paxos/paxos3001/my3001.cnf /data/paxos/greatsql3003/my3003.cnf    
$ sed -i 's/3001/3003/g' /data/paxos/greatsql3003/my3003.cnf
$ chown -R greatsql:greatsql /data/paxos/greatsql3003
$ sed -i 's#/data/paxos/paxos3003#/data/paxos/greatsql3003#g' /data/paxos/greatsql3003/my3003.cnf
$ /usr/local/greatsql/bin/mysqld --defaults-file=/data/paxos/greatsql3003/my3003.cnf --initialize-insecure
$ /usr/local/greatsql/bin/mysqld --defaults-file=/data/paxos/greatsql3003/my3003.cnf &

$ /usr/local/greatsql/bin/mysql -S /tmp/greatsql3003.sock


greatsql> CREATE USER 'repl'@'%' IDENTIFIED BY '123';
Query OK, 0 rows affected (10.02 sec)

greatsql> GREAT replication slave ON *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.00 sec)

greatsql> RESET MASTER;
Query OK, 0 rows affected (0.01 sec)

greatsql> SHUTDOWN;
Query OK, 0 rows affected (0.00 sec)

将之前备份的binlog放到这个单机实例里面作为临时复制binlog的主库

# 进到binlog目录里
$ cd greatsql3003/logs/
# 删除历史的binlog文件
$ \rm -rf mysql-bin.*
# 将之前备份的binlog文件拷贝过来
$ cp -a /backup/paxos-binlog/mysql-bin.* .
# 重新构建binlog的index索引文件
$ ls /data/paxos/greatsql3003/logs/mysql-bin.* > /data/paxos/greatsql3003/logs/mysql-bin.index
# 修改binlog属主属组权限
$ chown -R greatsql:greatsql /data/paxos/greatsql3003
# 最后启动greatsql3003实例
$ /usr/local/greatsql/bin/mysqld --defaults-file=/data/paxos/greatsql3003/my3003.cnf &
[1] 7202

# 登录greatsql3003实例
$ /usr/local/greatsql/bin/mysql -S /tmp/greatsql3003.sock

# 查看确认实例内可以看到备份的这些binlog
greatsql> SHOW BINARY LOGS;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000003 |       193 | No        |
| mysql-bin.000004 |  87720660 | No        |
| mysql-bin.000005 |   9590028 | No        |
| mysql-bin.000006 |   2642522 | No        |
| mysql-bin.000007 |    735834 | No        |
| mysql-bin.000008 |   3114129 | No        |
| mysql-bin.000009 |   2595175 | No        |
| mysql-bin.000010 |   4431921 | No        |
| mysql-bin.000011 |   4323716 | No        |
| mysql-bin.000012 |  10490537 | No        |
| mysql-bin.000013 |   3813720 | No        |
| mysql-bin.000014 |   4515287 | No        |
| mysql-bin.000015 |   4463553 | No        |
| mysql-bin.000016 |   4255894 | No        |
| mysql-bin.000017 |   2667369 | No        |
| mysql-bin.000018 | 163136954 | No        |
| mysql-bin.000019 |       193 | No        |
+------------------+-----------+-----------+
17 rows in set (0.00 sec)

此时登录greatsql3002实例,建立复制,去复制greatsql3003实例,并且复制的sql_thread线程需要停留到误操作删除DDL动作的gtid:‘3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:122961’

$ /usr/local/greatsql/bin/mysql -S /tmp/greatsql3002.sock

greatsql> CHANGE MASTER TO MASTER_HOST='192.168.56.221',
    ->     MASTER_PORT=3003,
    ->     MASTER_USER='repl',
    ->     MASTER_PASSWORD='123',
    ->     master_auto_position=1,
    ->     get_master_public_key=1;
Query OK, 0 rows affected, 9 warnings (0.02 sec)

greatsql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 192.168.56.221
                  Master_User: repl
                  Master_Port: 3003
                Connect_Retry: 60
              Master_Log_File: 
          Read_Master_Log_Pos: 4
               Relay_Log_File: zhangbei-node1-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: 
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 0
              Relay_Log_Space: 157
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 0
                  Master_UUID: 
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-12
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 1
            Network_Namespace: 
1 row in set, 1 warning (0.00 sec)


greatsql> START SLAVE io_thread;
Query OK, 0 rows affected, 1 warning (0.01 sec)

greatsql> START SLAVE sql_thread until sql_before_gtids='3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:122961';
Query OK, 0 rows affected, 1 warning (0.04 sec)

-- 以下复制还在追延迟
greatsql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 192.168.56.221
                  Master_User: repl
                  Master_Port: 3003
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000019
          Read_Master_Log_Pos: 193
               Relay_Log_File: zhangbei-node1-relay-bin.000002
                Relay_Log_Pos: 58259314
        Relay_Master_Log_File: mysql-bin.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 58260524
              Relay_Log_Space: 308504005
              Until_Condition: SQL_BEFORE_GTIDS
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 4653
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 2213003
                  Master_UUID: 260a57ad-4ad9-11f0-904f-00163ecf1759
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Waiting for replica workers to process their queues
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:13-122961
            Executed_Gtid_Set: 3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-12269
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 1
            Network_Namespace: 
1 row in set, 1 warning (0.00 sec)

-- 以下是复制延迟已经追完,并且sql_thread线程已经回放停止。
-- 并确认Executed_Gtid_Set信息应用到了: 3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:122960,说明停留在了误操作删除gtid之前的上一个gtid.
greatsql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 192.168.56.221
                  Master_User: repl
                  Master_Port: 3003
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000019
          Read_Master_Log_Pos: 193
               Relay_Log_File: zhangbei-node1-relay-bin.000030
                Relay_Log_Pos: 163136976
        Relay_Master_Log_File: mysql-bin.000018
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 163136768
              Relay_Log_Space: 163137915
              Until_Condition: SQL_BEFORE_GTIDS
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 2213003
                  Master_UUID: 260a57ad-4ad9-11f0-904f-00163ecf1759
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:13-122961
            Executed_Gtid_Set: 3001aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-122960
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 1
            Network_Namespace: 
1 row in set, 1 warning (0.00 sec)

检查之前的埋点数据,testdb.sbtest1表,id字段为1.

greatsql> SHOW TABLES FROM testdb;
+------------------+
| Tables_in_testdb |
+------------------+
| sbtest1          |
| sbtest2          |
| sbtest3          |
| sbtest4          |
| sbtest5          |
| sbtest6          |
| sbtest7          |
| sbtest8          |
+------------------+
8 rows in set (0.01 sec)

-- 此时看到买点数据
greatsql> SELECT * FROM testdb.sbtest1 WHERE id=1;
+----+------+-------+-------------------------------------------------------------+
| id | k    | c     | pad                                                         |
+----+------+-------+-------------------------------------------------------------+
|  1 | 6462 | wanli | 22195207048-70116052123-74140395089-76317954521-98694025897 |
+----+------+-------+-------------------------------------------------------------+
1 row in set (0.01 sec)

再将testdb库备份逻辑导出

注意参数–set-gtid-purged=OFF,不备份记录gtid。因为这些gtid在MGR集群上已经被执行过。

$ /usr/local/greatsql/bin/mysqldump -S /tmp/greatsql3002.sock \
> --set-gtid-purged=OFF --single-transaction --source-data=2 \
> --max-allowed-packet=32M -B testdb > testdb.sql

恢复到MGR集群主节点

$ time /usr/local/greatsql/bin/mysql -S /tmp/greatsql3001.sock -f < testdb.sql 
real   10m5.107s
user    0m0.168s
sys     0m0.046s

等到误操作删除的数据恢复后,再次查看埋点数据

# 登录MGR主节点
$ /usr/local/greatsql/bin/mysql -S /tmp/greatsql3001.sock testdb

greatsql> SELECT * FROM sbtest1 WHERE id=1;
+----+------+-------+-------------------------------------------------------------+
| id | k    | c     | pad                                                         |
+----+------+-------+-------------------------------------------------------------+
|  1 | 6462 | wanli | 22195207048-70116052123-74140395089-76317954521-98694025897 |
+----+------+-------+-------------------------------------------------------------+
1 row in set (0.00 sec)

greatsql> SHOW TABLES;
+------------------+
| Tables_in_testdb |
+------------------+
| sbtest1          |
| sbtest2          |
| sbtest3          |
| sbtest4          |
| sbtest5          |
| sbtest6          |
| sbtest7          |
| sbtest8          |
+------------------+
8 rows in set (0.01 sec)

总结

文章详细介绍了一种利用binlog和GTID机制恢复误操作数据库的方法。当发生DDL误操作(如误删数据库)时,可以通过以下步骤快速恢复数据:首先使用clone备份创建基础实例,然后通过解析binlog定位误操作的GTID位置,接着搭建伪主从复制环境,使SQL线程精确停止在误操作前。最后导出数据并恢复到原集群。这种方法能精确恢复到指定时间点,避免数据丢失,特别适合生产环境中突发误操作后的紧急恢复。整个过程充分利用了GreatSQL的binlog和复制功能,为DBA提供了一种高效可靠的数据恢复方案。

GreatSQL 8.0.32-24 今日发布 1.新增特性2.稳定性提升3.其他调整4.bug修复GreatSQL 8.0.32-24版本发布,增加并行load data、(逻辑 & CLONE)备份加密、MGR读写节点可绑定动态VIP、Oracle兼容扩展、审计日志增强等重磅特性。直播预告:GreatSQL 8.0.32-24发布会扫码预约发布会或点击下方阅读原文进行报名。 阅读详情

相关推荐

产品解读:GreatADM如何快速改造单实例为双主、MGR、读写分离架构?

进入paxos配置项中,我们仍选择【default】默认项目,对应的软件包版本可选择升级的新版本,在做架构改造时,同时进行数据库的版本升级工作。通过sysbench压入单机数据,通过备份单机数据,恢复到新的架构中,使用sysbench直接连接新的架构做压测,查看是否可正常运行验证数据可用性。创建备份集存储的目录,使用root创建,并调整目录权限,保证和添加服务时创建的【管理用户】,同一个属组,确保GreatADM以greatsql普通用户备份时,有权限写入/backup。形成双主双从,这里仅作演示。

GreatDB的博客 1388

5个步骤解决硬件监控数据异常:FanControl传感器插件故障排除新指南

你是否曾遇到硬件监控工具显示温度与实际手感不符的情况?当显卡风扇在游戏中突然全速运转,监控面板却显示温度正常——这种矛盾往往源于传感器插件故障。本文将通过五步法,帮助你解决硬件监控工具中传感器插件异常问题,涵盖从问题定位到长效优化的完整流程,让你彻底掌握传感器数据可信度验证与插件冲突解决技巧。 ## 定位异常现象:识别传感器插件故障特征 硬件监控工具的传感器插件异常往往表现为三类典型症状,这些

gitblog_00873的博客 681

ENU坐标系实战:5分钟搞定无人机导航中的站心坐标转换

本文针对无人机导航中GPS坐标与视觉感知不匹配的定位漂移问题,提供了基于ENU坐标系的实战解决方案。通过Python代码演示了如何快速、精准地实现地心地固坐标与站心坐标之间的转换,并详细解释了转换原理、精度对比及工程优化技巧,帮助开发者从根本上解决局部相对定位不准的难题。

mqtt6iot的博客 552

[MySQL] 记一次MGR组复制GTID(1236)异常的解决

现象: 应用服务向MGR其中一个节点发起写请求报错 mysql&gt; (3101, 'Plugin instructed the server to rollback the current transaction.') 检查该节点组同步报错 mysql&gt; SELECT * FROM performance_schema.replication_group_members; +...

Cindy的博客 3990

(超全面,超基础)Kriging插值推导理论笔记,算法,普通克里金

最近老师让我再重新推导一下克里金插值的方法如何求出预测结果,于是我又无数次地打开了大神的推导原理过程链接????:克里金(Kriging)插值的原理与公式推导 作者:xg1990,但是不可避免地在推导过程中,数学知识基础薄弱的我卡住在一些公式推导的步骤中。 所以就想基于上面大神的推导过程,将里面的推导写得更具体些,当然觉得毫不吃力可以进行推导的大神们可以不看我的注释,直接点开链接看就好。 我看到csdn中很多关于克里金推导的博客里面的内容直接截屏或者复制了上面链接里大神发表的内容,也不注

Olivel1997的博客 1万+

拌合楼管理软件开发(十一) 海康威视车牌识别摄像头安装调试,总算是跑通了。

/保存的文件个数这里之所以需要用到委托,直接更新textbox文本中的内容,以及复制picturebox的image会提示不是从齐创建的线程调用。

morsth的博客 4816

GreatSQL高可用架构揭秘:MGR集群从0到1搭建实战教程

GreatSQL作为一款开源免费数据库,凭借高可用、高性能、高兼容、高安全四大特性,已成为金融级应用场景的理想选择,也是MySQL与Percona Server for MySQL的完美替代方案。本文将带你从0到1亲手搭建一套基于MGR(MySQL Group Replication,组复制)的GreatSQL高可用集群,让你彻底掌握生产级数据库高可用架构的核心玩法。 ## 为什么选择Great

gitblog_00264的博客 138

python 抖音采集_python爬取抖音视频的实例详解

import requestsimport jsonimport reimport osfrom pprint import pprint as ppimport queueclass DouYin:header = {'accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*...

weixin_35795675的博客 1864

openEuler学习——部署MGR集群

MGR高可用的完整部署以及运维操作的简单讲解

2201_75878485的博客 1692

筹码峰五句口诀,看懂主力的秘密动作!(附实战图示)

筹码图的价值在于,它不像K线那样容易造假。主力可以骗线,但骗不了筹码分布。主力在不在;是吸筹还是出货;接下来是变盘还是震荡。这五句口诀可以说是“筹码阅读的入门圣经”:单峰坚挺变盘在即,双峰对垒高抛低吸;上峰不移主力在跑,多峰林立行情不止;下峰不移不离不弃,筹码识庄稳中取利!📌市场从来不是靠猜,而是靠看清。筹码,就是主力最真实的痕迹。如果你想学会提前布局、跟庄不被甩,学会看筹码峰——这一步必须打牢!

代码简单说 Vue、JAVA、PHP、Node.js 熟练运用,接口、架构、性能全搞定。 1164

099、多摄融合与变焦系统:广角到长焦的无缝切换算法

本文分享了多摄融合与变焦系统开发中的实战经验和关键挑战。作者通过一个旗舰机项目案例,揭示了广角到长焦切换时画面抖动问题的根源——融合算法误将视差当作运动补偿,并提出"视差冻结窗口"的解决方案。文章总结了三大多摄融合难点:物理视差处理、亮度差异补偿和切换时机把控,详细阐述了分层架构设计、融合权重计算等核心技术。同时强调了产线校准的重要性,并给出五项实用建议:允许边缘鬼影保留、参数场景化配置、加强产线检测、完善调试接口,以及合理运用AI技术。全文展现了多摄融合技术在时间、空间和感知维度上的复杂平衡艺术。

sundong_81的博客 48

GreatSQL MGR流控算法优化:如何彻底消除每60秒的性能抖动

在高可用数据库架构中,**GreatSQL** 作为一款开源免费数据库,凭借其高可用、高性能特性成为 MySQL 的理想替代方案。很多 DBA 在运维 MGR(MySQL Group Replication 组复制)集群时都遇到过一种"玄学"现象:业务吞吐量每隔 60 秒左右就会出现一次规律性的下跌,延迟随之飙升,然后又恢复如初。这种周期性性能抖动,根源往往不在 SQL 本身,而在 MGR 的流控

gitblog_00929的博客 429

(九)DFI接口时序

文章目录一、DFI Interface 一、DFI Interface   DFI接口是连接DDR Controller与DDR_PHY之间的通用接口,其信号组如下表:       

Mr.翟的博客 1万+

GreatSQL MGR智能选主机制详解:高可用切换不再靠运气

数据库高可用切换中,最让人揪心的时刻莫过于"主节点宕机后,谁来做新的主节点"。很多场景下,新主是**随机**选出来的,可能落在配置最差的机器上,也可能落在一个数据落后一大截的节点上——这就是典型的"选主靠运气"。**GreatSQL MGR(Group Replication,组复制)智能选主机制**彻底改变了这一局面,它让高可用切换变得**可预测、可控制、可优化**,是数据库运维人员值得深入了解

gitblog_00868的博客 412

【制作100个unity游戏之22】3DRPG游戏开发07——其他详细的设计

我们会有有很多单例,如果每个单例都去写会很麻烦,所以我们定义泛型单例模式 Singleton,我们将所有的单例都继承这个泛型单例,就省略很多重复的工作定义一个GameManager类,继承Singleton,控制整个游戏的进度,比如如果主角死了,广播,游戏结束调用。

向宇的博客,专注php/web全栈 unity游戏开发,欢迎大家评论纠错 2577

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

国产数据库之-GreatSQL

这次的EW争端,可能让很多人重新认识了软件国产化的重要性和急迫性。对企业级应用来说,芯片、操作系统、中间件、数据库这些都是俗称"卡脖子"的技术,例如数据库,各种国产数据库,可以说是百花齐放的状态,但这其中还是掺杂着各种问题,建荣写的这篇《从RDS算不算国产数据库谈起》就提到了一些,但无论怎样,国产化的道路,还是必须坚持的,需要技术人的沉淀、企业社区的支持、技术生态的创建,...

bisal的专栏 1892

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

GreatSQL社区2023全年技术文章总结

GreatSQL社区自成立以来一直致力于为广大的数据库爱好者提供一个交流与学习的平台。在2023年,我们见证了社区的蓬勃发展,见证了众多技术文章的诞生与分享。此篇总结呈现GreatSQL社区2023年社区技术文章在优快云发布的全部。这些文章涵盖了GreatSQL、MGR、源码解析、故障解析、SQL优化、安装部署、等众多数据库技术文章。

GreatSQL2021的博客 1223

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

GreatSQL是一个国内自主的开源数据库,可替代mysql

此外,GreatSQL社区还提供了MySQL Shell for GreatSQL,这是一个高级客户端和代码编辑器,支持JavaScript和Python脚本功能,以及与MySQL一起使用的API。它可以用来管理数据库,特别是对MGR的支持,可以方便地进行搭建、管理和配置。GreatSQL的架构可以分为连接层、服务层和存储引擎层。连接层负责与客户端建立连接,服务层是GreatSQL的核心,包括连接器、分析器、优化器、执行器等,而存储引擎层则负责数据的存储和提取。

地球空间 3193

GreatSQL入门完全指南:开源免费金融级数据库的五大核心特性一网打尽

对于正在寻找 MySQL 替代方案的开发者来说,**GreatSQL** 是一款不容错过的**开源免费数据库**。它可在普通硬件上满足**金融级数据库**场景,凭借高可用、高性能、高兼容、高安全等特性,成为 MySQL 与 Percona Server for MySQL 的理想可选替换。这篇 **GreatSQL 入门指南**,将带你一次看懂它的五大核心特性、安装方法与上手要点,帮助你快速评估它

gitblog_00059的博客 867

图文结合丨玩转MySQL Shell for GreatSQL

*GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。一、引言1.1 什么是MySQL Shell ?MySQL Shell 是 MySQL 的一个高级客户端和代码编辑器,是第二代 MySQL 客户端。第一代 MySQL 客户端即我们常用的 MySQL 。除了提供类似于 MySQL 的 SQL 功能外,MySQL Shell 还提供 JavaScript 和 Python...

老叶茶馆 541

图文结合丨带你轻松玩转MySQL Shell for GreatSQL

MySQL Shell 是 MySQL 的一个高级客户端和代码编辑器,是第二代 MySQL 客户端。第一代 MySQL 客户端即我们常用的 MySQL。除了提供类似于 MySQL 的 SQL 功能外,MySQL Shell 还提供 JavaScript 和 Python 脚本功能,并包括与 MySQL 一起使用的 API。MySQL Shell 除了可以对数据库里的数据进行操作,还可以对数据库进行管理,特别是对MGR的支持,使用MySQL Shell 可以非常方便的对MGR进行搭建、管理、配置等。

GreatSQL2021的博客 586

面向金融级应用的GreatSQL正式开源

本文首发于 GreatSQL社区 微信公众号。经过几个月的紧张筹备,GreatSQL宣布正式开源。GreatSQL是源于Percona Server的分支版本,除了Percona Serv...

老叶茶馆 510

多云部署多主模式的MGR集群,每个云一个MGR 节点,满足业务单元化改造的需求

欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答 GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。 本文来自投稿:by 作业帮DBA团队 一、架构需求: 正常情况下每个云的业务程序(下图中的APP) 通过本地的cetus 写入本地的MGR 节点(默认启动时通过cetus 配置本地MGR 节点为rw); 读请求会根据 cetus 读写分离策略路由到不同的云的MGR 节点 当本地MGR 节点故障,则.

GreatSQL2021的博客 561

GreatSQL配置文件my.cnf详解:新手必读的10个关键参数

GreatSQL 是一款开源免费、兼容 MySQL 的数据库,可在普通硬件上满足金融级高可用、高性能、高安全应用场景。对于刚接触 GreatSQL 的新手来说,**my.cnf 配置文件**是最先要掌握的技能——它决定了数据库实例的端口、存储路径、内存占用与性能表现。本文用通俗语言为你详解 my.cnf 中最关键的 10 个参数,帮你少踩坑、快上手。 ## 一、my.cnf 是什么?它在哪里?

gitblog_01097的博客 834

多云部署多主模式的MGR集群,每个云一个MGR 节点,是一种什么体验?

*GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。*本文来自投稿:by 作业帮DBA团队一、架构需求:正常情况下每个云的业务程序(下图中的APP) 通过本地的cetus 写入本地的MGR 节点(默认启动时通过cetus 配置本地MGR 节点为rw); 读请求会根据 cetus 读写分离策略路由到不同的云的MGR 节点当本地MGR 节点故障,...

老叶茶馆 373

GreatSQL 8.0.32-26 今日发布

等多方面都有增强新特性,包括 Clone 增量备份、压缩备份,MGR 新加入成员节点时自动选择最新数据节点为 donor 节点,NUMA 亲和性优化,非阻塞式 DDL,无主键表导入优化,更多 Oracle 兼容用法,最后登录信息,基于规则的数据脱敏功能等多个新特性。当有新成员节点加入 MGR 时,如果选择 Clone 方式复制数据,支持自动选择从最新事务数据的成员节点复制数据,可有效提升 Clone 速度,提高 MGR 的服务可靠性。当新加入节点触发 Clone 方式复制数据时,也支持该特性。

GreatSQL2021的博客 1255
上一篇: 5.7到8.0版本升级导致备份导入失败:提示 “超过行长度“
下一篇: 【无标题】
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值