二進制日誌配置和運維管理

在運維Mysql過程當中 一些有關二進制配置的選項和應用 ，包括 sync_binlog，max_binlog_cache_size，日子輪換,日誌清除,數據回滾 和恢復，誤操做的恢復等

1.sync_binlog 配置的性能與安全的考量
控制二進制日誌數據多久寫入磁盤一次
1.安全性的考慮,
sync_binlog=0  系統默認，二進制日誌並未顯式地被服務器寫入磁盤,可能會丟失1個或者多個事務的數據
sync_binlog=1 對於支持XA的事務引擎如innodb,不會丟失數據
2.性能的考慮
sync_binlog=0 性能不錯
sync_binlog=1 性能降低,根據業務不一樣,可能有20%左右的性能損耗
show variables like 'sync_binlog%';

mysql> show variables like 'sync_binlog%';+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 0     |
+---------------+-------+

是否把binlog的緩存刷新到磁盤
若是是1 就是在一個事務完成後把binlog的緩存刷新到磁盤

測試性能影響
sysbench  --num-threads=100 --max-requests=1000  --test=oltp  --db-driver=mysql  --mysql-host=192.168.1.250 --mysql-user=root --mysql-password='' prepare
建立表sbtest,10000條記錄寫入
運行測試
sysbench  --num-threads=100 --max-requests=1000  --test=oltp  --db-driver=mysql  --mysql-host=192.168.1.250 --mysql-user=root --mysql-password='' run

2.配置選項 binlog_cache_size=1M
事務緩存的內存大小
若是太小,事務大於緩存那部分數據會進入磁盤,形成性能降低
若是過大,服務器其它部分分配內存降低,形成性能降低
判斷事務日誌緩存進入磁盤是否過多過大
show global status like 'binlog_cache%';
binlog_cahce_disk_use(很小或是0 )
binlog_cache_use
max_binlog_cache_size=2M
二進制日誌最大的事務大小
預防大型事務可能阻塞二進制日誌太長時間,致使其它事務等待二進制日誌寫

3.日誌輪換
(1)手工輪換
flush logs
(2)自動輪換
設置 max_binlog_size 單個日誌文件的最大大小
大於最大大小會產生新的日誌文件
(3)mysql重啓
奔潰重啓 輪換

清除日誌
mysql裏
1.根據編號文件名
刪除mysql-bin.000100 以前的日誌 但不包括 mysql-bin.000100
purge binary logs to 'mysql-bin.000100';
2.根據時間
purge binary logs before '2017-02-18';
刪除 2017-02-18以前的日誌 但不包括 2017-02-18
3.自動刪除
設置過時時間
expire_logs_days=10(天)

二進制日誌和數據回滾和恢復
一.PITR數據庫定點即時恢復
PITR: point in time recovery 思路與步驟
step1 :恢復全備
step2 :利用二進制日誌恢復至指定的時間點
操做過程
1.使用innbackupex 工具進行全備
在/home/backup/
innobackupex --defaults-file=/etc/my.cnf  --user=root /home/backup

2.更新操做
 update1
 update2
 update3
update3是操做錯誤的,須要恢復到update3以前
3.恢復全備
停掉mysql服務
應用日誌
到  /home/backup/
innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log  2017-02-04_15-30-43/
cd /var/lib
mv mysql mysql20170204
mkdir mysql
chown -R mysql.mysql /var/lib/mysql
cd /home/backup
innobackupex --defaults-file=/etc/my.cnf --user=root --password='' --copy-back 2017-02-04_15-30-43/
出現
innobackupex: completed OK!
表示恢復成功完成

4.使用mysqlbinlog工具過濾日誌,恢復至更新update3的日誌位置
查看全備時的起始位置
cd 2017-02-04_15-30-43/
cat xtrabackup_binlog_info
二進制文件名  位置
cd var/log/mysql
mysqlbinlog  --base64-output='decode-rows' -vvv  --start-pos=107  --stop--pos=731  mysql-bin.000100 >100.sql
mysql<100.sql

誤操做的恢復在二進制日誌目錄下mysqlbinlog  --base64-output='decode-rows' -vvv   mysql-bin.000100 >100.sql在100.sql中查找相關的紀錄(row模式下經過註釋)生產中腳本處理