㈠ mysql binlog可否恢復刪除數據
MySQL開啟binlog後,寫入操作都會記錄到二進制日誌里,可以使用mysqlbinlog查看/導出/恢復數據.
假設你之內前進行了 mysqlmp全量備份容,和binlog增量備份(在mysqlmp全量備份時使用參數--flush-logs清除全量備份前的binlog).
先恢復之前用mysqlmp進行的全量備份,然後用 mysqlbinlog進行時間點還原:
?
mysql -uroot -prootpwd db_name < db_name.sql
mysqlbinlog --stop-datetime="2013-10-12 12:30:00" /var/log/mysql/mysql-bin.000001 | mysql -uroot -prootpwd
這里假設你的誤操作發生在 2013-10-12 12:30:00之後.
如果你既沒有進行mysqlmp全量備份,也沒有開啟binlog安全日誌,那真的就悲劇了.
㈡ mysql表誤刪 怎麼恢復 未 開啟binlog
mysql binlog沒有開啟數抄據恢復襲 mysql 不小心誤刪了一個數據表的數據，通過delete，沒有開啟binlog，如何才可以恢復數據。MYI MYD文件還是原大校 SQL code? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 MariaDB [(none)]> show varia...
㈢ mysql的binlog可以刪除嗎
怎麼樣安全刪除mysql下的binlog日誌_網路經版驗：權
http://jingyan..com/article/60ccbceb11477d64cab197cf.html
㈣ 怎樣打開查看mysql binlog
1 在my.ini(window)配置文件裡面來
[mysqld]
log-bin=mysql-bin(名字可以隨自便起)
我們每次進行操作的時候，File_size都會增長
2、show binlog events
4. 用mysqlbinlog 工具來顯示記錄的二進制結果，然後導入到文本文件，為了以後的恢復。
詳細過程如下：
bin>mysqlbinlog --start-position=4 --stop-position=106 mysqlbin-log.000001 > D:\\test1.txt
或者全部導出:
bin>mysqlbinlog mysqlbin-log.000001 >D:\\test1.txt
㈤ mysql 如何復製表 binlog最小
復制之所以工作得益於MySQL把對資料庫的變更都記錄在 binlog中，然後主庫把它讀出來，放到從庫上去應用。當然binlog 的用途不僅限於此，比如 PITR等
在5.1.4版本以前，binlog格式只能是 statement -based replication ,在以後的版本中引入了 row-based replication 以及 mixed-based replication。
下面我會簡單的介紹一下SBR、RBR、MBR 這三種格式下binlog是如何組織的，更重要的是在這三種格式下，replication是如何進行工作的。當然我主要介紹 RBR模式下的復制，因為RBR模式下我們的復制是認為是最安全的方式，即使是使用MBR也會有可能踩到坑。
在MySQL中，Binlog有兩類文件，一類文件用於記錄數據變更，一類文件用於記錄binlog list。
Binlog list文件就是 ${HOSTNAME}-bin.index ；用於記錄當前有哪些binlog
binlog的數據文件名字類似於 ${HOSTNAME}-bin.00001,這類文件是我們重點關注的對象。
先來大概的看看binlog 的文件內容：
svan-mac:mydata xiean$ mysqlbinlog -vvvv mysql-bin.000010
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#151218 15:19:30 server id 5331 end_log_pos 123 CRC32 0xd483743a Start: binlog v 4, server v 5.7.9-log created 151218 15:19:30
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
grNzVg/
oAEjQA
ATp0g9Q=
'/*!*/;
# at 123
#151218 15:19:30 server id 5331 end_log_pos 154 CRC32 0x622c3733 Previous-GTIDs
# [empty]
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
抽一段binlog出來看看：
# at 141
#151218 15:19:30 server id 5331 end_log_pos 245
Query thread_id=3350 exec_time=11 error_code=0
at 141
當前事件在文件中的起始位置，單位bytes
#151218 15:19:30
當前事件開始時間
Server id
當前事件在哪個Server 執行的
End_log_pos
下一個事件在文件中的開始位置，即當前事件內容為 4~end_log_pos-1范圍
exec_time
執行所花費的時間(如果是Master )；
error_code
執行該事件時的結果
我們把Binlog 文件拆分成3個部份
簡單描述 －－>
{
"header": "desc …",
"event": "xxxxxxx",
"footer": "log rotat"
}
第一部份： 由 4-bytes 開始，這4-bytes 表明它是一個MySQL binlog 文件（由log_event.h 這個文件常量：BINLOG_MAGIC (0xfe 0x62 0x69 0x6e = 0xfe 'b''i''n') 表示），這也就能解釋我們的第一個event 為什麼 起始位置是 4 了原因了。
第二部份： 一個一個的 event ，每個event 根據binlog版本不同，解釋出來的含義有所不同(在MySQL 5.0＋ binlog版本都使用的是 V4版本)
第三部份：也就是文件最後event用於記錄log-rotation 事件，表明了接下來的日誌將寫入哪個文件。
Event 是binlog 記錄的最小單位，event 的上一級是event group ，復制或者恢復的時候基於 event group 來重放日誌。對於一個組來說，要麼都執行， 要麼都不執行。而對於DML來說一個 event 包含多個event，而對於DDL 來說，一個event 就是一個 event group。對於每個Event里邊有哪些東西，以及event group 是如何劃分的我們將在下面討論。
觸發器，存儲過程，函數在MySQL里邊是如何處理的呢？
觸發器，存儲過程，函數 在創建的時候都會記錄Binlog
觸發器在執行的時候 Master、Slave 都會被調用，Master上的觸發器將會在Master上被調用，Slave上的觸發器將會在Slave上被調用。
存儲過程在執行的時候，Master上會被轉化成具體的SQL語句存儲在Binlog里邊，因此在binlog里邊是看不到任何 call 來調用存儲過程的event 。
函數在執行的時候並不會被解析成為具體的語句，相反函數執行時和觸發器比較相像，在Master上和Slave都會被調用。
三種模式下Binlog 是如何記錄的
基於語句的復制 ： 是MySQL 5.7.7 版本以前默認配置，它將SQL語句（而不是實際的數據變化）從主伺服器復制到從伺服器。
優點 ：在某些情況下，最終寫入日誌文件的數據更少，例如更新或者刪除許多行時。對於隻影響幾行數據的簡單語句，基於行的復制佔用的空間更少。
缺點 ： 最明顯的是它不支持不確定性的語句，例如當前時間函數。
基於行的復制 ： 使用單個的錶行記錄變化，而不是語句。主伺服器將消息，也就是事件寫入二進制日誌，表示單個錶行的變化。這與其他RDBMS中更加傳統的復制方式類似。
優點：需要更少的鎖定，意味著能夠達到更高的並發。
缺點：它會產生更多需要記錄的數據，佔用的空間大。
混合模式日誌 ： 可以根據要記錄的事件實時改變二進制日誌格式。使用混合模式復制時，默認採用基於語句的復制，但是在某些情況下自動切換到基於行的復制
㈥ mysql怎樣通過binlog恢復被惡意刪除的數據
1. 以前我錯誤的認為mysql的日誌可以恢復到任何時間的狀態，其實並不是這樣，這個恢復是有前提的，就是你至少得有一個從日誌記錄開始後的資料庫備份，通過日誌恢復資料庫實際上只是一個對以前操作的回放過程而已，不用想得太復雜，既然是回放你就得注意了，如果你執行了兩次恢復那麼就相當於是回放了兩次，後果如何你自己應該清楚了吧。
2. 要想通過日誌恢復資料庫，在你的my.cnf文件里應該有如下的定義，log-bin=mysql-bin，這個是必須的.binlog-do-db=db_test,這個是指定哪些資料庫需要日誌，如果有多個資料庫就每行一個，如果不指定的話默認就是所有資料庫.
[mysqld]
log-bin=mysql-bin
binlog-do-db=db_test
binlog-do-db=db_test2
3.刪除二進制日誌:
a.mysql> system ls -ltr /var/lib/mysql/bintest*;
mysql>reset master(清空所有的二進制日誌文件)
b.purge master logs to 'bintest.000006';(刪除bintest.000006之前的二進制日誌文件)
c.purge master logs before '2007-08-10 04:07:00'(刪除該日期之前的日誌)
d.在my.cnf 配置文件中[mysqld]中添加:
expire_logs_day=3設置日誌的過期天數,過了指定的天數,會自動刪除
4.下面就是恢復操作了
特別提示，mysql每次啟動都會重新生成一個類似mysql-bin.000003的文件，如果你的mysql每天都要重新啟動一次的話，這時候你就要特別注意不要選錯日誌文件了。
(注意：下面有一些技巧，這些東西才是最寶貴的喲，普通的東東手冊上都有，這可是我摸索出來的喲，別人我都不告訴他。
技巧1 :
在下面你將看到 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd 類似的語句，但是它一次只能操作一個日誌文件，如果你變通一下變成這樣 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.0* | mysql -u root -pmypwd 那麼它基本上就會表示出的所有的日誌文件了，這樣可解決你忘記在哪一個日誌文件中的問題，當然你也可以用這種寫法更完美,mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.[0-9]* | mysql -u root -pmypwd ，看到[0-9]*這個東東了吧，它表示以數字開頭的任何字元，方便吧！
技巧2:
你可以通過--one-database 參數選擇性的恢復單個資料庫，example在下面，爽吧。
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test
技巧3:
如果你老人家已經使用過 /usr/local/mysql5/bin/mysqlbinlog --start-date="2005-04-20 9:55:00" /var/data/mysql5/mysql-bin.0* > /home/db/tt.sql 類似的語句將日誌導成了ASCII文本文件，那麼你就可以直接在phpmyadmin或者其它什麼亂七糟八的的客戶端里執行這個文件文件就行了，因為它本身就是一個標準的sql文件，比如想讓文件裡面的某些語句不執行，OK，it's easy,找到它們刪除即可，然後再放進去執行就OK滴啦！這個可是灰常灰常的爽喲。。。。。。
技巧4:
我來給大家講一下，下面這條語句都做了什麼
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test
這是把mysql-bin.000001這個二進制文件里的內容轉換成ASCII文件(也就是sql語句)，直接通過管道操作符"|"傳輸給 mysql這個程序，然後過濾掉其它資料庫的語句，只在db_test里執行。
技巧5:
著了，多打了一個技巧，現在暫時沒內容，等以後再加吧！！！
)
下面部份摘錄自網上。
如果MySQL伺服器啟用了二進制日誌，你可以使用mysqlbinlog工具來恢復從指定的時間點開始 (例如，從你最後一次備份)直到現在或另一個指定的時間點的數據。關於啟用二進制日誌的信息，參見5.11.3節，「二進制日誌」。對於 mysqlbinlog的詳細信息，參見mysql手冊8.6節，「mysqlbinlog：用於處理二進制日誌文件的實用工具」。
要想從二進制日誌恢復數據，你需要知道當前二進制日誌文件的路徑和文件名。一般可以從選項文件(即my.cnf or my.ini，取決於你的系統)中找到路徑。如果未包含在選項文件中，當伺服器啟動時，可以在命令行中以選項的形式給出。啟用二進制日誌的選項為-- log-bin。要想確定當前的二進制日誌文件的文件名，輸入下面的MySQL語句：
SHOW BINLOG EVENTS G
你還可以從命令行輸入下面的內容：
mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS G'
將密碼my_pwd替換為伺服器的root密碼。
1. 指定恢復時間
對於MySQL 4.1.4，可以在mysqlbinlog語句中通過--start-date和--stop-date選項指定DATETIME格式的起止時間。舉例說明，假設在今天上午10:00(今天是2005年4月20日)，執行SQL語句來刪除一個大表。要想恢復表和數據，你可以恢復前晚上的備份，並輸入：
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
該命令將恢復截止到在--stop-date選項中以DATETIME格式給出的日期和時間的所有數據。如果你沒有檢測到幾個小時後輸入的錯誤的SQL語句，可能你想要恢復後面發生的活動。根據這些，你可以用起使日期和時間再次運行mysqlbinlog：
mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
在該行中，從上午10:01登錄的SQL語句將運行。組合執行前夜的轉儲文件和mysqlbinlog的兩行可以將所有數據恢復到上午10:00前一秒鍾。你應檢查日誌以確保時間確切。下一節介紹如何實現。
2. 指定恢復位置
也可以不指定日期和時間，而使用mysqlbinlog的選項--start-position和--stop-position來指定日誌位置。它們的作用與起止日選項相同，不同的是給出了從日誌起的位置號。使用日誌位置是更准確的恢復方法，特別是當由於破壞性SQL語句同時發生許多事務的時候。要想確定位置號，可以運行mysqlbinlog尋找執行了不期望的事務的時間范圍，但應將結果重新指向文本文件以便進行檢查。操作方法為：
mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00"
/var/log/mysql/mysql-bin.000001 > /tmp/mysql_restore.sql
該命令將在/tmp目錄創建小的文本文件，將顯示執行了錯誤的SQL語句時的SQL語句。你可以用文本編輯器打開該文件，尋找你不要想重復的語句。如果二進制日誌中的位置號用於停止和繼續恢復操作，應進行注釋。用log_pos加一個數字來標記位置。使用位置號恢復了以前的備份文件後，你應從命令行輸入下面內容：
mysqlbinlog --stop-position="368312" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
上面的第1行將恢復到停止位置為止的所有事務。下一行將恢復從給定的起始位置直到二進制日誌結束的所有事務。因為mysqlbinlog的輸出包括每個SQL語句記錄之前的SET TIMESTAMP語句，恢復的數據和相關MySQL日誌將反應事務執行的原時間。
㈦ 如何動態監控mysql binlog
有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。前者使用起來比較簡便。推薦使用。
1. check table 和 repair table
登陸mysql 終端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出現的結果說Status是OK，則不用修復，如果有Error，可以用：
repair table tabTest;
進行修復，修復之後可以在用check table命令來進行檢查。在新版本的phpMyAdmin裡面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk適用於MYISAM類型的數據表，而isamchk適用於ISAM類型的數據表。這兩條命令的主要參數相同，一般新的系統都使用MYISAM作為預設的數據表類型，這里以myisamchk為例子進行說明。當發現某個數據表出現問題時可以使用：
myisamchk tablename.MYI
進行檢測，如果需要修復的話，可以使用：
myisamchk -of tablename.MYI
關於myisamchk的詳細參數說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL伺服器沒有訪問這個數據表，保險的情況下是最好在進行檢測時把MySQL伺服器Shutdown掉。
另外可以把下面的命令放在你的rc.local裡面啟動MySQL伺服器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL監聽的Sock文件位置，對於使用RPM安裝的用戶應該是/var/lib/mysql/mysql.sock，對於使用源碼安裝則是/tmp/mysql.sock可以根據自己的實際情況進行變更，而pathtochk則是myisamchk所在的位置，DATA_DIR是你的MySQL資料庫存放的位置。
需要注意的時，如果你打算把這條命令放在你的rc.local裡面，必須確認在執行這條指令時MySQL伺服器必須沒有啟動！檢測修復所有資料庫(表)
㈧ 如何查看mysql binlog
有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。前者使用起來比較簡便。推薦使用。
1. check table 和 repair table
登陸mysql 終端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出現的結果說Status是OK，則不用修復，如果有Error，可以用：
repair table tabTest;
進行修復，修復之後可以在用check table命令來進行檢查。在新版本的phpMyAdmin裡面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk適用於MYISAM類型的數據表，而isamchk適用於ISAM類型的數據表。這兩條命令的主要參數相同，一般新的系統都使用MYISAM作為預設的數據表類型，這里以myisamchk為例子進行說明。當發現某個數據表出現問題時可以使用：
myisamchk tablename.MYI
進行檢測，如果需要修復的話，可以使用：
myisamchk -of tablename.MYI
關於myisamchk的詳細參數說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL伺服器沒有訪問這個數據表，保險的情況下是最好在進行檢測時把MySQL伺服器Shutdown掉。
㈨ 如何查看mysql binlog中的具體sql語句
基於row模式的binlog，生成DML(insert/update/delete)的rollback語句
通過mysqlbinlog -v 解析binlog生成可讀的sql文件
提取需要處理的有效sql
"### "開頭的行專.如果輸入的start-position位於某屬個event group中間，則會導致"無法識別event"錯誤！
㈩ mysqlbinlog 怎麼將資料庫恢復到指定的時間
mysqlbinlog 怎麼復將資料庫恢復制到指定的時間
先用數據備份以norecovery的方式恢復到最近時間點，然後再恢復日誌備份(如中間有多份則都用norecovery方式恢復)，最後一份選擇特定時間及recovery方式。