記一次MySQL資料誤刪-恢復體驗

阿新 • • 發佈：2018-12-12

資料誤刪了怎麼辦？本文也許能給您一定的提示。

一、檢視日誌

資料無意中發現不見了，怎麼辦？

也許首先想到的是去查日誌，找到問題原因，但是這個時間有可能會比較長，並且線上的業務在這段時間會收到影響。

因此，先不要去管什麼原因，首先應該做的第一件事情應當是資料恢復，保證正常的業務不受影響，而後再回過來查詢原因即可。

那麼，想要恢復資料，首先想到的也是日誌：有無所有SQL操作的記錄日誌，有無開啟binlog同步日誌。這樣才能根據SQL記錄重新恢復資料，否則，資料將無法找回。

其次，我們需要查以下MySQL伺服器開啟了哪些日誌，於是首先檢視MySQL的配置檔案 /etc/my.cnf ，發現開啟了errorlog、slowlog和binlog，這時就可以鬆一口氣了，因為只要有binlog，所有資料都將找得回來，slowlog對我們當前的問題來說並沒有什麼用，errorlog後面我們拿來查詢問題原因也許會有用。

[client]
port = 3306
socket = /tmp/mysql.sock
default-character-set = utf8mb4

[mysql]
prompt="MySQL [\d]> "
no-auto-rehash

[mysqld]
port = 3306
socket = /tmp/mysql.sock

basedir = /usr/local/mysql
datadir = /data/mysql
pid-file = /data/mysql/mysql.pid
user = mysql
bind-address = 0.0.0.0
server-id = 1

init-connect = 'SET NAMES utf8mb4'
character-set-server = utf8mb4

skip-name-resolve
#skip-networking
back_log = 300

max_connections = 1916
max_connect_errors = 6000
open_files_limit = 65535
table_open_cache = 1024
max_allowed_packet = 500M
binlog_cache_size = 1M
max_heap_table_size = 8M
tmp_table_size = 128M

read_buffer_size = 2M
read_rnd_buffer_size = 8M
sort_buffer_size = 8M
join_buffer_size = 8M
key_buffer_size = 256M

thread_cache_size = 64

query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M

ft_min_word_len = 4

log_bin = mysql-bin
binlog_format = mixed
expire_logs_days = 7

log_error = /data/mysql/mysql-error.log
slow_query_log = 1
long_query_time = 1
slow_query_log_file = /data/mysql/mysql-slow.log

performance_schema = 0
explicit_defaults_for_timestamp

#lower_case_table_names = 1

skip-external-locking

default_storage_engine = InnoDB
innodb_file_per_table = 1
innodb_open_files = 500
innodb_buffer_pool_size = 1024M
innodb_write_io_threads = 4
innodb_read_io_threads = 4
innodb_thread_concurrency = 0
innodb_purge_threads = 1
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 2M
innodb_log_file_size = 32M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120

bulk_insert_buffer_size = 8M
myisam_sort_buffer_size = 64M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1

interactive_timeout = 28800
wait_timeout = 28800

[mysqldump]
quick
max_allowed_packet = 500M

[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 8M
read_buffer = 4M
write_buffer = 4M

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798

[client]port=3306socket=/tmp/mysql.sockdefault-character-set=utf8mb4[mysql]prompt

="MySQL [\d]> "no-auto-rehash[mysqld]port=3306socket=/tmp/mysql.sockbasedir=/usr/local/mysqldatadir=/data/mysqlpid-file=/data/mysql/mysql.piduser=mysqlbind-address=0.0.0.0server-id=1init-connect='SET NAMES utf8mb4'character-set-server=utf8mb4skip-name-resolve#skip-networkingback_log=300max_connections=1916max_connect_errors=6000open_files_limit=65535table_open_cache=1024max_allowed_packet=500Mbinlog_cache_size=1Mmax_heap_table_size=8Mtmp_table_size=128Mread_buffer_size=2Mread_rnd_buffer_size=8Msort_buffer_size=8Mjoin_buffer_size=8Mkey_buffer_size=256Mthread_cache_size=64query_cache_type=1query_cache_size=64Mquery_cache_limit=2Mft_min_word_len=4log_bin=mysql-binbinlog_format=mixedexpire_logs_days=7log_error=/data/mysql/mysql-error.logslow_query_log=1long_query_time=1slow_query_log_file=/data/mysql/mysql-slow.logperformance_schema=0explicit_defaults_for_timestamp#lower_case_table_names = 1skip-external-lockingdefault_storage_engine=InnoDBinnodb_file_per_table=1innodb_open_files=500innodb_buffer_pool_size=1024Minnodb_write_io_threads=4innodb_read_io_threads=4innodb_thread_concurrency=0innodb_purge_threads=1innodb_flush_log_at_trx_commit=2innodb_log_buffer_size=2Minnodb_log_file_size=32Minnodb_log_files_in_group=3innodb_max_dirty_pages_pct=90innodb_lock_wait_timeout=120bulk_insert_buffer_size=8Mmyisam_sort_buffer_size=64Mmyisam_max_sort_file_size=10Gmyisam_repair_threads=1interactive_timeout=28800wait_timeout=28800[mysqldump]quickmax_allowed_packet=500M[myisamchk]key_buffer_size=256Msort_buffer_size=8Mread_buffer=4Mwrite_buffer=4M

此外，我們通過 show variables 命令檢視當前MySQL變數發現，其實MySQL還有另外一類日誌，叫做generallog

| general_log      | OFF |
| general_log_file | /data/mysql/localhost.log |

12	\|general_log\|OFF\|\|general_log_file\|/data/mysql/localhost.log\|

當前伺服器沒有開啟該日誌，該日誌用以記錄所有執行的SQL語句，它和binlog的區別在於：

1、generallog僅僅是記錄的日誌文字檔案，而binlog原本是拿來進行伺服器之間的資料同步用的，是一個二進位制檔案；

2、binlog記錄了比generallog更全面的SQL執行記錄，而generallog提供的文字日誌可讀性更強；

二、恢復資料

找到了binlog，那麼我們需要從binlog中恢復資料。

1、檢視當前有哪些binlog檔案

MySQL [hhzl_gdg]> show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000005 |  17160082 |
| mysql-bin.000006 |    890082 |
| mysql-bin.000007 |  27160082 |
+------------------+-----------+
3 rows in set (0.00 sec)

123456789

MySQL[hhzl_gdg]>show binary logs;+------------------+-----------+|Log_name|File_size|+------------------+-----------+|mysql-bin.000005|17160082||mysql-bin.000006|890082||mysql-bin.000007|27160082|+------------------+-----------+3rows inset(0.00sec)

發現有3個binlog檔案，我們再來檢視當前正在使用的binlog檔案是哪個：

MySQL [hhzl_gdg]> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000007 | 27160082 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

1234567

MySQL[hhzl_gdg]>show master status;+------------------+----------+--------------+------------------+-------------------+|File|Position|Binlog_Do_DB|Binlog_Ignore_DB|Executed_Gtid_Set|+------------------+----------+--------------+------------------+-------------------+|mysql-bin.000007|27160082||||+------------------+----------+--------------+------------------+-------------------+1row inset(0.00sec)

發現是 mysql-bin.000007檔案。瞭解的資訊差不多了，我們進入到MySQL的資料存放目錄 /data/mysql/，先將這幾個binlog檔案備份起來，以便防止資料丟失，並且後面也許還需要再從這幾個檔案查詢資料丟失原因。

cd /data/mysql/
mkdir -p ~/mysql-bin-backup
cp mysql-bin.* ~/mysql-bin-backup/ -r

123	cd/data/mysql/mkdir-p~/mysql-bin-backupcpmysql-bin.*~/mysql-bin-backup/-r

由於對於我們當前的業務來說，被刪除的資料僅僅是2017-08-01到2017-08-25之間的重要資料，因此，我們僅需要恢復這段時間的資料即可，從mysql-bin.000007這個檔案匯出這個時間段的sql：

mysqlbinlog --no-defaults --start-datetime='2017-08-01 00:00:00' --stop-datetime='2017-08-25 00:00:00' -d hhzl_gdg /root/mysql-bin-backup/mysql-bin.000007 > ~/2017-08-01_2047-08-25.sql

1	mysqlbinlog--no-defaults--start-datetime='2017-08-01 00:00:00'--stop-datetime='2017-08-25 00:00:00'-dhhzl_gdg/root/mysql-bin-backup/mysql-bin.000007>~/2017-08-01_2047-08-25.sql

執行完成之後使用mysql命令進入mysql控制檯，use 需要恢復資料的資料庫，執行source命令即可：

use hhzl_gdg;
source /root/2017-08-01_2047-08-25.sql

12	usehhzl_gdg;source/root/2017-08-01_2047-08-25.sql

參考連結：

記一次MySQL資料誤刪-恢復體驗

一、檢視日誌

記一次MySQL資料誤刪-恢復體驗

記一次MySQL刪庫的資料恢復

記一次mysql數據庫刪除恢復的案例

記一次mysql事故---紀念逝去的一上午

記一次mysql中文字符亂碼的問題排查

記一次MySQL存儲過程和遊標的使用

記一次Mysql魔鬼實訓

記一次MySQL遷移並從MySQL5.6升級到5.7後查詢慢了幾十倍的問題

記一次Oracle資料故障排除過程

記一次RAC資料節點2自動重啟故障解決

記一次MySQL安裝出現的坑爹問題。。。

記一次 MySQL semaphore crash 的分析（有彩蛋）

記一次Oracle資料遷移中文亂碼問題

記一次Mysql佔用記憶體過高的優化過程

記一次資料庫伺服器中毒癱瘓恢復感受

記一次MHA主從不同步恢復過程

記一次MYSQL建表失敗得bug（暫未解決！，求助）

記一次mysql去重查詢與刪除重複記錄

記一次mysql物理備份

oracle表資料誤刪恢復，表誤刪恢復

記一次MySQL資料誤刪-恢復體驗

一、檢視日誌

相關推薦