MYSQL簡單的binlog恢復測試
日常的資料備份及恢復測試，是DBA工作重中之重的事情，所以要做好備份及測試，日常的備份常見有mysqldump+binlog備份、xtrabackup+binlog備份，無論那一種，幾乎都少不了對binlog的備份，說明了binlog在資料恢復中的重要性，下面做個小測試，是工作中不少運維或者新人DBA容易犯的錯。
建立一個測試表tb1：
<test>([email protected]) [xuanzhi]> show create table tb1\G *************************** 1. row *************************** Table: tb1 Create Table: CREATE TABLE `tb1` ( `id` int(10) NOT NULL AUTO_INCREMENT, `name` char(10) CHARACTER SET latin1 DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.00 sec) <test>([email protected]) [xuanzhi]>
往表裡插入兩條資料：
<test>(root@localhost) [xuanzhi]> insert into tb1 (name) value ('aa'),('bb'); Query OK, 2 rows affected (0.01 sec) Records: 2 Duplicates: 0 Warnings: 0 <test>(root@localhost) [xuanzhi]> show master logs; +----------------------+-----------+ | Log_name | File_size | +----------------------+-----------+ | localhost-bin.000001 | 329 | +----------------------+-----------+1 row in set (0.00 sec) <test>(root@localhost) [xuanzhi]>
這個時候對資料備份，如果是xtrabackup備份的話，會在有xtrabackup_binlog_info檔案中記錄此時備份是到那個binlog檔案和pos點的，如果是mysqldump備份，則需要帶上--master-data=2這個引數，下面我們的資料量少，用mysqldump備份：
[[email protected] ~]# mysqldump -uroot -p123456 -R --events --triggers=true --master-data=2 --single-transaction xuanzhi > xuanzhi.sql Warning: Using a password on the command line interface can be insecure. [[email protected] ~]# grep -i "CHANGE MASTER" xuanzhi.sql -- CHANGE MASTER TO MASTER_LOG_FILE='localhost-bin.000001', MASTER_LOG_POS=329; [[email protected] ~]#
備份完後，繼續模擬資料庫有寫入，而還是寫在localhost-bin.000001
<test>(root@localhost) [xuanzhi]> insert into tb1 (name) value ('cc'),('dd'); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 <test>(root@localhost) [xuanzhi]> show master logs; +----------------------+-----------+ | Log_name | File_size | +----------------------+-----------+ | localhost-bin.000001 | 538 | +----------------------+-----------+ 1 row in set (0.00 sec) <test>(root@localhost) [xuanzhi]> flush logs; Query OK, 0 rows affected (0.01 sec) <test>(root@localhost) [xuanzhi]> insert into tb1 (name) value ('ee'); Query OK, 1 row affected (0.00 sec) <test>(root@localhost) [xuanzhi]> show master logs; +----------------------+-----------+ | Log_name | File_size | +----------------------+-----------+ | localhost-bin.000001 | 589 | | localhost-bin.000002 | 321 | +----------------------+-----------+ 2 rows in set (0.00 sec) <test>(root@localhost) [xuanzhi]>
上面我們進行flush logs是為了模擬現在已經有多個binlog檔案了，恢復時進行多個binlog一起恢復。
進行誤操，把xunazhi庫drop了：
<test>(root@localhost) [xuanzhi]> drop database xuanzhi; Query OK, 1 row affected (0.02 sec) <test>(root@localhost) [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ 4 rows in set (0.00 sec) <test>(root@localhost) [(none)]>
建立資料xuanzhi，把備份匯入：
<test>(root@localhost) [(none)]> create database xuanzhi; Query OK, 1 row affected (0.00 sec)
[[email protected] ~]# mysql -uroot -p123456 xuanzhi <./xuanzhi.sql Warning: Using a password on the command line interface can be insecure. [[email protected] ~]#
檢視資料：
<test>(root@localhost) [(none)]> use xuanzhi Database changed <test>(root@localhost) [xuanzhi]> select * from tb1; +----+------+ | id | name | +----+------+ | 1 | aa | | 2 | bb | +----+------+ 2 rows in set (0.00 sec) <test>(root@localhost) [xuanzhi]>
可以看到備份前的資料恢復了，我們現在要結合Binlog來恢復，但前提要找出誤操作前的pos點，也就是drop database xuanzhi前的pos點：
[[email protected] ~]# mysqlbinlog -v --base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database" ### INSERT INTO `xuanzhi`.`tb1` ### SET ### @1=5 ### @2='ee' # at 290 #170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78 COMMIT/*!*/; # at 321 #170327 21:19:25 server id 1313306 end_log_pos 422 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1490620765/*!*/; drop database xuanzhi /*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET [email protected]_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; [[email protected] ~]# mysql -uroot -p123456 xuanzhi <./xuanzhi.sql Warning: Using a password on the command line interface can be insecure. [[email protected] ~]#
從上面可以看到，誤操作前的pos點是321，那我們現在通過binlog來進行資料恢復：
[[email protected] mysql-5.6]# mysqlbinlog --start-position=329 --stop-position=321 localhost-bin.000001 localhost-bin.000002 |mysql -uroot -p123456 xuanzhi Warning: Using a password on the command line interface can be insecure. [[email protected] mysql-5.6]#
--start-position是備份後記錄下的pos點， --stop-position是誤操前的pos點，如果批多個binlog檔案，那麼start-position是第一個binlog檔案的pos點，stop-position是最後一個binlog的pos點，下面我們看下資料是否恢復回來了：
<test>(root@localhost) [xuanzhi]> select * from tb1; +----+------+ | id | name | +----+------+ | 1 | aa | | 2 | bb | | 3 | cc | | 4 | dd | | 5 | ee | +----+------+ 5 rows in set (0.00 sec) <test>(root@localhost) [xuanzhi]>
這裡要提的是進行恢復前，要把需要恢復的binlog備份好，或者移動拷貝一份到另一個目錄，因為進行資料匯入時也會繼續寫binlog。假如你沒有誤操作的情況下，就是想測試一下資料的恢復，很多人的操作是匯入備份，再從備份裡記錄的binlog檔名和pos點進行binlog恢復，發現步驟都很完美，也沒報錯，恢復後就是隻有備份時的資料，沒有備份後的資料，下面測試一下給大家看：
<test>(root@localhost) [xuanzhi]> insert into tb1 (name) value ('aa'),('bb'); Query OK, 2 rows affected (0.01 sec) Records: 2 Duplicates: 0 Warnings: 0 <test>(root@localhost) [xuanzhi]> select * from tb1; +----+------+ | id | name | +----+------+ | 1 | aa | | 2 | bb | +----+------+ 2 rows in set (0.00 sec) <test>(root@localhost) [xuanzhi]> show master logs; +----------------------+-----------+ | Log_name | File_size | +----------------------+-----------+ | localhost-bin.000001 | 329 | +----------------------+-----------+ 1 row in set (0.00 sec) <test>(root@localhost) [xuanzhi]>
進行備份操作：
[[email protected] ~]# mysqldump -uroot -p123456 -R --events --triggers=true --master-data=2 --single-transaction xuanzhi > xuanzhi.sql Warning: Using a password on the command line interface can be insecure. [[email protected] ~]# grep -i "change master" xuanzhi.sql -- CHANGE MASTER TO MASTER_LOG_FILE='localhost-bin.000001', MASTER_LOG_POS=329; [[email protected] ~]#
繼續寫localhost-bin.000001後進行flush logs生成新的binlog再繼續寫資料，這裡只是想模擬localhost-bin.000001寫滿了切localhost-bin.000002，結合多個binlog一起恢復
<test>([email protected]) [xuanzhi]> insert into tb1 (name) value ('cc'),('dd'); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 <test>([email protected]) [xuanzhi]> flush logs; Query OK, 0 rows affected (0.00 sec) <test>([email protected]) [xuanzhi]> insert into tb1 (name) value ('dd'); Query OK, 1 row affected (0.01 sec) <test>([email protected]) [xuanzhi]> show master logs; +----------------------+-----------+ | Log_name | File_size | +----------------------+-----------+ | localhost-bin.000001 | 589 | | localhost-bin.000002 | 321 | +----------------------+-----------+ 2 rows in set (0.00 sec) <test>([email protected]) [xuanzhi]>
下面進行恢復測試，正常來說先把備份匯入：
相關推薦
MYSQL簡單的binlog恢復測試
日常的資料備份及恢復測試，是DBA工作重中之重的事情，所以要做好備份及測試，日常的備份常見有mysqldump+binlog備份、xtrabackup+binlog備份，無論那一種，幾乎都少不了對binlog的備份，說明了binlog在資料恢復中的重要性，下面做個小測試
Mysql使用binlog恢復數據解決誤操作問題的兩種方法
tle osi net 回滾 href bsp databases affect 恢復 為保證沒有其他參數配置影響，重新安裝配置了一臺最小化安裝的CentOS7虛擬機
1. 基礎知識?
安裝mysql5.6數據庫Mysql binlog初步理解
2. 配置mysql 開啟
Windows下MySQL的binlog恢復
nta 更多 scp 第一步 ahk psc vra 3rd sna 前言
在最近的工作中，由於自己粗（zuo）心（si）誤update操作導致幾百行的數據出現錯誤，在心急如焚的同時（那時候我竟然不知道除了備份之後還有binlog日誌恢復）立馬查資料學習binlog的
mysql根據binlog恢復資料
mysql根據binlog恢復資料
建立表
mysql> CREATE TABLE `test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
mysql利用binlog恢復資料
需求：需要給開發提供一個2018年9月30號的資料，按照我們公司正常備份策略來說，直接找到對應時間的備份資料，解壓匯入即可，恰好這個時間節點的資料沒有，只備份到2018年9月25號的，糟糕了吧
咋辦呢，咱們利用binlog日誌來恢復吧，如果二進位制日誌都沒有，那還恢復啥呢，運維咋當滴
mysql利用binlog恢復資料詳細例子
模擬資料恢復的案例
一、update未加where條件，誤操作修改資料
在生產環境中，我們搭建了mysql主從，備份操作都是在從備份資料庫上
前提：有最近一天或者最近的全備
或者最近一天相關資料庫的備份
最重要的是，二進位制日誌必須完整
全備命令： mysqldump
mysql使用binlog恢復使用delete誤刪的資料
在我們平時使用MySQL資料庫的時候,可能會出現delete from table_name 忘記寫條件語句而導致刪除了整個表的資料。
這個時候就很棘手了。如果公司的資料庫都有開啟資料備份那自然是沒有問題。source 一下備份下來的sql檔案就好。
但是如果沒有備份
mysql通過Binlog恢復資料到sql檔案實戰
通過日誌恢復資料的前提是開啟了mysql-binlog日誌。
檢視是否啟用了日誌
mysql>show variables like ‘log_bin’;
檢視當前的日誌
mysql> show master status;
圖中mys
使用mysql的binlog恢復誤操作(update|delete)的資料
binlog格式介紹
MYSQL binlog複製主要有三種方式：基於SQL語句的複製(statement-based replication, SBR)，基於行的複製(row-based replication, RBR)，混合模式複製(mixed-bas
Windows下，MySql使用binlog恢復表和資料初級教程
今天給大家分享一個Windows下，MySql使用binlog恢復表和資料的初級教程！大家也知道，小編寫教程是很詳細，保證小白都可以看得懂！但是過程很痛苦啊，一步一步的寫。所以呢，喜歡小編的就請點個贊吧，讓我有走下去的動力！教程開始，準備工作，要先開啟binlog日誌的功能對
nodejs之mysql簡單查詢例項測試程式碼
var mysql = require('mysql');
var moment = require('moment');
var TEST_DATABASE = 'test1';
var TEST_TABLE = 'table_test';
var client =
mysql 通過binlog恢復數據
binlog mys .cn img bin events mit limit event 1.查看數據庫配置參數，是否開啟log_bin
2.查看binlog文件有哪些
3.查binlog文件
show binlog events in ‘mysql-bin
mysql binlog 日誌詳解，恢復測試
二進位制日誌常用引數：
max_binlog_size ：單個二進位制日誌檔案的最大值，超過該值，則產生新的二進位制日誌檔案，並記錄到.index檔案，預設1G。
binlog_cache_size: 使用InnoDB時，所有未提交的事務會記錄到一個快取中，等待事務提交時
Mysql 通過全量備份和binlog恢復整體數據
mysql 通過全量備份和binlog恢復整體數據 某天工作時間，一個二貨犯暈登錯生產當測試環境了，直接drop了一個數據庫,需要緊急恢復!可利用備份的數據文件以及增量的 binlog 文件進行數據恢復。具體思路歸納幾點：1、恢復條件為 MySQL 要開啟 binlog 日誌功能，並且要全備和增量的所有
Mysql之binlog日誌說明及利用binlog日誌恢復數據操作記錄
Language 命令 ani art ase 回來 log日誌 slaves update 眾所周知，binlog日誌對於mysql數據庫來說是十分重要的。在數據丟失的緊急情況下，我們往往會想到用binlog日誌功能進行數據恢復（定時全備份+binlog日誌恢復增量數據部
利用binlog恢復mysql資料庫資料
前提：mysql資料庫開啟了binlog日誌
通過 show variables like 'log_%'; 檢視是否開啟binlog日誌。
操作步驟：
在資料庫中
mysql binlog 恢復
開始先執行每天自動備份的資料庫
show master status;
再使用binlog恢復
binlog直接恢復資料庫,不建議直接使用
mysqlbinlog --start-datetime="2018-8-11 02:00:00" C:\Users\dona
基於binlog恢復mysql資料庫
找到對應時間的binlog檔案
mysqlbinlog --no-defaults --base64-output=decode-rows -v -v /var/lib/mysql/mysql-bin.000538| sed -n '/### DELETE FROM `cl
[轉帖]PG的簡單備份恢復 找時間進行測試
轉帖PG的簡單使用
https://blog.csdn.net/lk_db/article/details/77971634
一： 純檔案格式的指令碼： 示例：1. 只匯出postgres資料庫的資料，不包括模式 -s pg_dump -U postgres -f /po
mysql的binlog災難恢復
binlog 基本認識
MySQL的二進位制日誌可以說是MySQL最重要的日誌了，它記錄了所有的DDL和DML(除了資料查詢語句)語句，以事件形式記錄，還包含語句所執行的消耗的時間，MySQL的二進位制日誌是事務安全型的。
一般來說開啟二進位制日誌大概會有1