GreatSQL通过伪装从库回放Binlog文件
<h1 id="greatsql通过伪装从库回放binlog文件">GreatSQL通过伪装从库回放Binlog文件</h1><h2 id="一适用场景说明">一、适用场景说明</h2>
<p>1、主库误操作恢复</p>
<p>利用 Binlog 在其他实例解析、回放，根据gtid只回放到指定位点。</p>
<p>2、网络隔离环境同步</p>
<p>备份恢复后可以拉去主库Binlog文件至新实例同步增量数据。</p>
<p>3、备份恢复遇到Binlog文件过大处理</p>
<p>恢复实例时有可能主库的 Binlog 超过限定大小，无法用mysqlbinlog工具恢复。</p>
<blockquote>
<p>以上只是列举部分场景，而且恢复的方式也并非一种，本文讲解通过伪装从库的方式去回放所需的binlog。</p>
</blockquote>
<h2 id="二测试环境实例信息">二、测试环境实例信息</h2>
<table>
<thead>
<tr>
<th>实例1</th>
<th>192.168.138.239:3301</th>
</tr>
</thead>
<tbody>
<tr>
<td>实例2</td>
<td>192.168.135.196:3302</td>
</tr>
</tbody>
</table>
<h2 id="三实例1生成测试数据">三、实例1生成测试数据</h2>
<p>在实例1创建4个新库，用sysbench生成测试数据，每执行一次sysbench就刷新一下Binlog，生成多个Binlog文件。</p>
<pre><code class="language-sql">192.168.138.239:3301
create database wl_greatsql1;
create database wl_greatsql2;
create database wl_greatsql3;
create database wl_greatsql4;
sysbench ./src/lua/oltp_read_write.lua
--mysql-db=wl_greatsql1-4
--mysql-host=192.168.138.239
--mysql-port=3301
--mysql-user=greatsql
--mysql-password='QW12er#$'
--mysql-ignore-errors=all
--tables=5
--table_size=10000
--threads=10
--report-interval=2
--time=1800
prepare
</code></pre>
<p>通过<code>flush logs;</code>命令生成多个Binlog文件。</p>
<pre><code class="language-C">-rw-r-----. 1 greatsql greatsql 9545477 Jun4 17:53 binlog.000001
-rw-r-----. 1 greatsql greatsql 9544713 Jun4 17:54 binlog.000002
-rw-r-----. 1 greatsql greatsql 9544713 Jun4 17:54 binlog.000003
-rw-r-----. 1 greatsql greatsql 9544713 Jun4 17:54 binlog.000004
</code></pre>
<h2 id="四查看实例2状态">四、查看实例2状态</h2>
<p>实例2的状态确保没有重复数据记录，做了<code>reset master</code>以及<code>slave</code>。</p>
<pre><code class="language-SQL">greatsql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: binlog.000001
Position: 153
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)
greatsql> SHOW SLAVE STATUS\G
Empty set, 1 warning (0.00 sec)
</code></pre>
<h2 id="五实例2伪装从库应用实例1binlog数据">五、实例2伪装从库应用实例1binlog数据</h2>
<p>1、处理实例2的slave信息</p>
<pre><code class="language-Plain"># reset slave;之后relaylog就被全清了变成以下样子
-rw-r----- 1 greatsql greatsql 177 Apr4 02:32 relaylog.000001
-rw-r----- 1 greatsql greatsql51 Apr4 02:32 relaylog.index
</code></pre>
<p>关于 <code>RESET SLAVE</code> 的操作说明：</p>
<pre><code class="language-Plain">RESET SLAVE
会移除当前从库的复制状态信息。
会删除所有和该从库关联的 relay log（中继日志）文件。
会将与复制位点（例如 Master_Log_File、Read_Master_Log_Pos 等）相关的信息重置为空。
不会清除通过 CHANGE MASTER TO 设置的复制连接参数（如主库地址、用户、密码等），在较新的 GreatSQL 版本中这些连接参数会保留。
RESET SLAVE ALL
会执行与 RESET SLAVE 相同的操作（删除 relay log、重置复制状态）。
此外，还会清空通过 CHANGE MASTER TO 配置的所有主库连接信息（主库地址、端口、用户、密码等），相当于是把复制相关的所有设置都恢复到初始默认状态。
</code></pre>
<p>2、将实例1生成的binlog文件传输到实例2主机并修改名称</p>
<pre><code class="language-bash">#拷贝到实例2。
binlog.000001
binlog.000002
binlog.000003
binlog.000004
#修改名称
mv binlog.000001 relaylog.000002
mv binlog.000002 relaylog.000003
mv binlog.000003 relaylog.000004
mv binlog.000004 relaylog.000005
#修改权限
chown -R greatsql:greatsql /greatsql/dbdata/log/
</code></pre>
<p>3、修改实例2 relay-bin.index文件</p>
<pre><code class="language-SQL"># 修改实例2 index文件内容同上。
vi relaylog.index
# 新增
/greatsql/dbdata/log/relaylog.000002
/greatsql/dbdata/log/relaylog.000003
/greatsql/dbdata/log/relaylog.000004
/greatsql/dbdata/log/relaylog.000005
</code></pre>
<p>4、实例2建立复制通道</p>
<p>说明：</p>
<p>只需要sql_thread即可应用relay log，io_thread并不用配置实际的信息。关键是在执行 <code>CHANGE MASTER TO</code> 操作时要指定 <code>RELAY_LOG_FILE</code> 和 <code>RELAY_LOG_POS</code> 的详细信息。</p>
<pre><code class="language-sql"># 建立slave通道
CHANGE MASTER TO MASTER_HOST='source2.example.com', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_PORT=3301, Relay_Log_File='relaylog.000001', Relay_Log_POS=4;
</code></pre>
<p>5、启动sql_thread</p>
<pre><code class="language-sql"># 只启动sql线程
START SLAVE sql_thread;
# 如果想指定位点恢复可执行下面的命令，加上 SQL_AFTER_GTIDS 参数
START SLAVE sql_thread UNTIL SQL_AFTER_GTIDS = 'AAAAAAAA-0000-0000-0000-000000000000:XXX';
</code></pre>
<p>6、查看实例2的复制通道</p>
<pre><code class="language-sql"># 查看master信息
greatsql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: binlog.000001
Position: 38179345
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 32ab2502-3492-11f0-891f-00163e7e5561:1-124
1 row in set (0.00 sec)
# 查看slave信息
greatsql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: source2.example.com
Master_User: repl
Master_Port: 3301
Connect_Retry: 60
Master_Log_File:
Read_Master_Log_Pos: 4
Relay_Log_File: relaylog.000006
Relay_Log_Pos: 4
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: No
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: 4
Relay_Log_Space: 153
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: 0
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: /greatsql/dbdata/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates
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: 32ab2502-3492-11f0-891f-00163e7e5561:1-124
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set, 1 warning (0.00 sec)
</code></pre>
<p>6、数据验证</p>
<pre><code class="language-sql">greatsql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| wl_greatsql1 |
| wl_greatsql2 |
| wl_greatsql3 |
| wl_greatsql4 |
+--------------------+
8 rows in set (0.01 sec)
greatsql> USE wl_greatsql1
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
greatsql> SHOW TABLES;
+------------------------+
| Tables_in_wl_greatsql1 |
+------------------------+
| sbtest1 |
| sbtest2 |
| sbtest3 |
| sbtest4 |
| sbtest5 |
+------------------------+
5 rows in set (0.00 sec)
greatsql> SELECT COUNT(*) FROM sbtest1;
+----------+
| count(*) |
+----------+
| 10000 |
+----------+
1 row in set (0.01 sec)
</code></pre>
<h2 id="六操作风险">六、操作风险</h2>
<h3 id="1确认伪从库已有数据是否安全兼容回放操作"><strong>1、确认伪从库已有数据是否安全兼容回放操作</strong></h3>
<ul>
<li>如果伪从库中<strong>本身已存在部分数据</strong>，必须提前核实与 Binlog 中即将回放的数据是否存在冲突，避免出现主键冲突、重复插入、逻辑错误等情况。</li>
<li>建议在回放前执行一次结构与关键数据校验，确保数据状态与预期一致。</li>
</ul>
<h3 id="2主库误操作场景需精准识别回放的事务范围"><strong>2、主库误操作场景需精准识别回放的事务范围</strong></h3>
<ul>
<li>若回放 Binlog 是为了<strong>修复主库误操作</strong>（如误删、误更新等），必须提前通过 <code>mysqlbinlog</code> 工具明确要回放的具体事务，避免出现“多执行”或“漏执行”。</li>
<li>回放应尽量以事务为单位分批控制，必要时使用 <code>START SLAVE UNTIL</code> 或 <code>mysqlbinlog --stop-position</code> 等方式精准切点。</li>
</ul>
<h3 id="3严控伪从库的主从配置避免误接入真实主库"><strong>3、严控伪从库的主从配置，避免误接入真实主库</strong></h3>
<ul>
<li>伪装从库的核心在于模拟中继日志环境，不应真实接入主库。</li>
<li>配置 <code>CHANGE MASTER TO</code> 时，务必使用<strong>虚假地址或</strong>，防止误连主库造成非预期的主从同步或写入操作。</li>
</ul>
<hr>
<p>Enjoy GreatSQL 😃</p>
<h2 id="关于-greatsql">关于 GreatSQL</h2>
<p>GreatSQL是适用于金融级应用的国内自主开源数据库，具备高性能、高可靠、高易用性、高安全等多个核心特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。</p>
<p>相关链接： GreatSQL社区 Gitee GitHub Bilibili</p>
<h2 id="greatsql社区">GreatSQL社区：</h2>
<blockquote>
<p>社区博客有奖征稿详情：https://greatsql.cn/thread-100-1-1.html</p>
</blockquote>
<p><img src="https://img2024.cnblogs.com/other/2630741/202507/2630741-20250704103745529-1476120854.png"></p>
<h2 id="技术交流群">技术交流群：</h2>
<blockquote>
<p>微信：扫码添加<code>GreatSQL社区助手</code>微信好友，发送验证信息<code>加群</code>。</p>
</blockquote>
<p><img src="https://img2024.cnblogs.com/other/2630741/202507/2630741-20250704103745765-643228194.png"></p><br><br>
来源：https://www.cnblogs.com/greatsql/p/18965178
頁:
[1]