在mysql5.7的版中使用了gtid複製，可以多執行緒複製，同時也省去了記binlog起始點的煩惱；
但是在一次測試環境中通過binlog日誌來恢復誤刪資料時卻耗了不少時間；
[root@mysql-01 tmp]
# mysqlbinlog --no-defaults mysql-bin.000018 --start-position="4" --stop-position="1102" |mysql test
error 1781 (hy000) at line 17: @@session.gtid_next cannot be set to uuid:number when @@global.gtid_mode = off.
哪怕你檢視的已經是off了；
mysql>
show
global variables like
'gtid_mode';+
---------------+-------+
| variable_name |
value|+
---------------+-------+
| gtid_mode |
off|
+---------------+-------+
1row
inset
(0.00 sec)
set @@global.gtid_mode
= off_permissive;
mysqlbinlog --no-defaults --start-position=
"441" mysql-bin.00000*| mysql test
binlog日誌恢復
檢視mysql是否開啟binlog 進mysql操作 mysql show variables like log bin 查詢binlog檔名 mysql show master status 進mysql操作 查mysqlbinlog工具的位置,每個人都不同自行變更 結果是mysql bin.例如...
通過binlog日誌檔案恢復單錶 小技巧
場景 某天執行了delete from t1操作忘加where條件，我們需要通過昨天的全量備份 誤操作之前的binlog增量備份，加以恢復。在通過mysqlbinlog解析時，需要用sed命令去過濾出t1表的insert delete update操作，如果binlog檔案很多，並且預設是1g的大小...
通過binlog日誌檔案恢復單錶 小技巧
場景 某天執行了delete from t1操作忘加where條件，我們需要通過昨天的全量備份 誤操作之前的binlog增量備份，加以恢復。在通過mysqlbinlog解析時，需要用sed命令去過濾出t1表的insert delete update操作，如果binlog檔案很多，並且預設是1g的大小...