mysql point in time recovery using sql_thread SQL_Thread增量恢復binlog 要點
一、mysql point in time recovery using sql_thread SQL_Thread增量恢復binlog,網上有很多類似文章,這裡把我實驗的要點記錄下來:
二、
1)重新初始化一個例項,
恢復全量備份檔案。
2)找到第一個binlog檔案的position,和剩下所有的binlog。
3)將binlog偽裝成relaylog,透過sql thread增量恢復。
三、將relay log info的repository改到file中,並生成這個檔案。
-
SET GLOBAL relay_log_info_repository='FILE';
-
CHANGE MASTER TO master_host='1';
並且透過該步驟,生成 relay.info 檔案。 -
假如不想生成relay_log.info檔案可以使用如下語句:
CHANGE MASTER TO RELAY_LOG_FILE='mysql-relay-bin.000001', RELAY_LOG_POS=1, MASTER_HOST='dummy';
四、關閉例項,將需要增量的binlog檔案偽裝成relaylog。
[root@mysql1 mysql]# for i in $(ls /tmp/binlogs/*.0*)
do
ext=$(echo $i | cut -d'.' -f2);
cp $i mysql-relay-bin.$ext;
done
chown mysql:mysql -R .
五、修改relay.info檔案和relay-log.index檔案
如果沒有生成relay_log.info檔案,本步驟可以忽略
-
將relay.info的第二三行改成需要執行的第一個binlog(現在是relaylog)的檔名和position:
-
/data/mysql57/relaylog/mysql - relay . 000003
-
1276895
第二三行對應Relay_log_name和Relay_log_pos,等同於:
mysqlbinlog mysql-relay.000003 --start-position=1276895 | mysql -u -p -S
修改該檔案是為了告訴SQL_Thread從哪一個檔案和哪一個position開
始執行事務
再修改relay-log.index,清空原有資訊,新增以下資訊,為的是告訴SQL_Thread還有哪些
relaylog是需要執行的。
-
/data/mysql57/relaylog/mysql-relay.000003
-
/data/mysql57/relaylog/mysql-relay.000004
-
/data/mysql57/relaylog/mysql-relay.000005
-
/data/mysql57/relaylog/mysql-relay.000006
-
/data/mysql57/relaylog/mysql-relay.000007
-
/data/mysql57/relaylog/mysql-relay.000008
-
/data/mysql57/relaylog/mysql-relay.000009
-
/data/mysql57/relaylog/mysql-relay.000010
六、 啟動例項,開啟SQL_Thread:
-
START SLAVE sql_thread ;
只需要開啟SQL_Thread即可
mysql> CHANGE MASTER TO RELAY_LOG_FILE='mysql1-relay-bin.000001', RELAY_LOG_POS=1, MASTER_HOST='dummy'; mysql> set global slave_parallel_type='LOGICAL_CLOCK'; mysql> SET GLOBAL SLAVE_PARALLEL_WORKERS=8; mysql> START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = '7766037d-4d1e-11e7-8a51-08002718d305:25076';
該測試使用的版本為
:MySQL 5.7.22
如果沒有使用gtid模式,請使用如下語句:將START SLAVE sql_thread後新增一個
UNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos 即可。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30393770/viewspace-2168905/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 備份恢復Lesson 04.Using the RMAN Recovery Catalog
- MySQL crash recovery恢復慢分析MySql
- MySQL 透過 binlog 恢復資料MySql
- MySQL 通過 binlog 恢復資料MySql
- 05、MySQL Case-MySQL binlog誤清除恢復MySql
- 利用binlog日誌恢復mysql資料MySql
- 【Mysql】如何透過binlog恢復資料MySql
- Mysql效能壓測、Binlog恢復資料MySql
- RMAN增量恢復
- MySQL中的binlog相關命令和恢復技巧MySql
- MySQL閃回技術之binlog2sql恢復binlog中的SQLMySql
- study critical point and saddle point using Hessian Matrix
- MySQL binlog基於時間點恢復資料失敗是什麼鬼?MySql
- MySQL運維之binlog_gtid_simple_recovery(GTID)MySql運維
- rman 增量備份恢復
- oracle基於SCN增量恢復Oracle
- 資料恢復:FonePaw Data Recovery for Mac資料恢復Mac
- MySQL Binlog 增量同步工具 go-mysql-transfer 實現詳解MySqlGo
- Mysqldump 在備庫進行備份時會阻塞備庫的sql_threadMySqlthread
- oracle 增量備份恢復驗證Oracle
- office文件恢復軟體(magic office recovery)
- mysql 誤刪除表內資料,透過binlog日誌恢復MySql
- 教你自動恢復MySQL資料庫的日誌檔案(binlog)MySql資料庫
- 基於percona xtrabackup 2.4.14的增量備份恢復還原mysql 5.6MySql
- 使用binlog2sql恢復資料SQL
- VMware Live Recovery 9.0 - 多雲實時恢復
- 硬碟資料恢復工具:Eassiy Data Recovery for mac硬碟資料恢復Mac
- iPhone資料恢復工具:Cisdem iPhone Recovery for MaciPhone資料恢復Mac
- Joyoshare iPhone Data Recovery MaciPhone資料恢復工具iPhoneMac資料恢復
- 用增量備份來快速恢復dg
- MySQL使用mysqldump+binlog完整恢復被刪除的資料庫(轉)MySql資料庫
- 資料庫資料恢復—無備份,binlog未開啟的Mysql資料庫資料恢復案例資料庫資料恢復MySql
- PostgreSQL12中實現增量備份與任意時間點恢復SQL
- Linux上透過binlog檔案恢復mysql資料庫詳細步驟LinuxMySql資料庫
- iPhone資料恢復工具:TunesKit iPhone Data Recovery for MaciPhone資料恢復Mac
- EaseUS Data Recovery Wizard Mac資料恢復軟體Mac資料恢復
- Macos專業資料恢復工具:Aiseesoft Data Recovery for MacMac資料恢復AI
- 【Xtrabackup】Xtrabackup全備、增量備份及恢復示例