mysql临时开启二进制_关于MySQL二进制日志Binlog的认识
MySQL的二進制日志可以說或是MySQL最重要的日志了,它記錄了所有的DDL和DML(除了數據查詢語句)語句,以事件形式記錄,還包含語句所執行的消耗的時間,MySQL的二進制日志是失誤安全型的.
在5.1的版本你二進制日志還替代了原本的更新日志.一般來說開啟二進制日志大概會有1%的性能損耗(參見MySQL官方中文手冊5.1.24版).二進制有兩個最重要的使用場景:
其一是:MySQL Replication在Master端開啟binlog,Mster把它的二進制日志傳遞給slaves來達到master-slave數據一直的目的.
其二:自然就是數據恢復了,通過使用mysqlbinlog工具來恢復數據.
binlog不支持select,show一類語句,如果要記錄這些語句可以通過打開MySQL的general log來大到目的.
可以利用mysqlbinlog工具來查看二進制日志,打開一個正在使用的binlog
$mysqlbinlog var/mysql-bin.000022
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#091222 18:09:33 server id 2? end_log_pos 106?? Start: binlog v 4, server v 5.1.41-debug-log created 091222 18:09:33 at startup
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
ROLLBACK/*!*/;
# at 106
#091222 23:20:35 server id 2? end_log_pos 174?? Query?? thread_id=4???? exec_time=1???? error_code=0
SET TIMESTAMP=1261495235/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1/*!*/;
SET @@session.sql_mode=0/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
BEGIN
/*!*/;
# at 174
#091222 23:20:35 server id 2? end_log_pos 269?? Query?? thread_id=4???? exec_time=0???? error_code=0
use test/*!*/;
SET TIMESTAMP=1261495235/*!*/;
insert bench values(20,'xiaojj')
/*!*/;
# at 269
#091222 23:20:35 server id 2? end_log_pos 296?? Xid = 22
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET
COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/
;
mysqlbinlog有一些選項可以使用,簡單說明常用選項:
-d,--database=name :指定數據庫名稱,只列出指定數據庫的操作.
-D, --disable-log-bin :執行恢復的時候,禁止二進制日志.可以防止同一臺MySQL加上-t時進入死循環
-o,--offset=n :忽略掉日志前n行命令
-r,--result-file=name :將輸出日志到指定文件
-R, --read-from-remote-server :從一個MySQL服務器上讀取二進制
-s,--short-form :顯示簡單格式,省略一些信息
-S, --socket=name? :socket文件連接path.
-t, --to-last-log? :和-R一起使用,在二進制日志結束的時候并不會停止,而是在MySQL服務器最后生成的binlog結束,如果輸出和輸入都在一臺MySQL上可能會導致死循環.
--set-charset=char-name :在輸出文本格式的時候,在第一行加上set names char-name.
--start-datetime=# --stop-datetime=# :指定輸出起始日期的日志.
--start-position=# --stop-position=# :指定起始日志的位置.
一個典型的恢復例子如下
$mysqlbinlog -d=binlog var/mysql-bin.000022|mysql –uroot –p
#在本地恢復binlog數據庫數據操作.
MySQL的二進制日志量的繁忙的服務器上是巨大的,尤其是使用了row級別記錄binlog日志量更是驚人,長時間不管理的話會非常浪費磁盤空間,通常刪除日志有以下幾種方法:
reset master在執行reset master之后會清空所有二進制日志,新日志會從*****-000001開始
purge
master logs這個命令有2中用法:其一,purge master logs to
'mysql-bin.000022'形式的意思是將編號22之前的日志全部刪除,其二是purge master logs
before'yyyy-mm-dd HH(24):mm:ss'是將指定時間之前的binlog全部刪除
第三種方法就是在mysqld加入--expire_logs_days=n設置日志的有效期為n天.
binlog是以二進制形式保存的,所以并不能像慢查詢日志那樣可以直接查看.binlog有3種記錄形式分別是:
STATEMENT:基于sql語句級別的binlog,每一條修改數據的sql都會被保存到binlog里.
ROW:
基于行級別的,他會記錄每一行記錄的變化,就是將每一行的修改都記錄到binlog里面,記錄的非常詳細,在replication里面也不會因為存儲過
程觸發器等造成Master-Slave數據不一致的問題,但是有個致命的缺點日志量比較大.由于要記錄每一行的數據變化,當執行update語句后面不
加where條件的時候或alter table的時候,產生的日志量時驚人的.
MIXED:在mixed下默認是statement,但是在下列情況下會切換到row狀態:
.當一個DML更新一個ndb引擎表
.使用uuid()函數的時候,這是由于uuid()Universal Unique Identifier每次在運行的時候產生的值都是唯一的
.當2個或更多的表同時被更新且有auto_increment列的時候
.任意的insert delayed被執行的時候
.當一個視圖需要row-based replication時候,比如一個sql在創建視圖的時候使用了uuid()函數
.調用一個UDF
.
如果一個語句使用的時row,同時這個語句還在使用了一些臨時表,所有后來的語句都會以row方式記錄(除了使用那些臨時表的).直到該客戶端斷開所有的
臨時表.臨時表是不能使用row方式的,因此,一旦row被使用,那么后來的使用那個表的語句就是不安全的,所以近似于這個客戶端在斷開所有臨時表的時候
是不安全的.
.還有一些函數如found_rows(),row_count(),user(),current_user()以及系統變量(部分session級別的除外)
.在最近的MySQL版本里面當使用mysql數據庫里面的log表,或者使用load_fileio()函數
幾乎所有的engine都支持row級別的binlog,但是statement級別的在innodb上只有隔離級別是repeatable read和serializable時支持.
當操作影響mysql數據庫grant表的時候,有以下情況:
.當grant表被直接修改的時候例如使用insert,update,delete,replace,do,load data file,truncate,select等語句的時候使用的時候相應的設定的系統設定的類型來記錄binlog.
.
當是有grant,create user,revoke,set password,rename
user,drop,alter,create(除了create
table...select...)都將使用statement級別來記錄binlog而忽視系統設置.
create table...select是一個集數據定義和數據處理為一體的語句.他的create table部分使用statement方式,而select部分使用系統定義的方式.
可以通過啟動的時候加上--binlog-format=row|statement|mixed來指定binlog級別.還可以寫道my.cnf里面的[mysqld]里面,當然在MySQL運行中通過set命令也可以修改binlog的級別.例如
mysql>set global binlog_format=’row’;
mysql>set global binlog_format=1;#和row一樣,同樣2和statement,3和mixed也是一樣的級別
binlog_format的默認值不同版本也不相同,應使用"show variables like '%binlog%';"查看
有以下幾種原因,當一個replication在運行的時候,轉換binlog_format可能會導致一個錯誤:
.有一個存儲過程函數或觸發器
.ndb存儲引擎是可用的
.replication正在進行的使用row級別且打開臨時表的session
系統參數,關于二進制日志的一些選項:
--binlog-row-event-max-size選項,使用row級別時指定,當一個時間的所有行小于這個值才會被記錄到binlog,單位是byte,該數值必須是256的整數倍,默認是1024.
使用show variables like "%bin%";的部分變量
--log-bin=0|1 二進制日志是否開啟
--binlog-format=statement|row|mixed 二進制日志的級別statement,row或mixed
--max-binlog-size=# 二進制日志文件的最大尺寸,但這并不是嚴格的.
--binlog-cache-size=# 事務進行過程中存儲二進制日志的緩存大小,系統會為每個session分配指定大小的空間
--max-binlog-cache-size=# 表示的時二進制日志最大可使用的內存,如果數值國小會導致系統報錯.
--innodb-locks-unsafe-for_binlog=0|1 控制在innodb表中使用insert into ...select語句時是否鎖定源表,on不鎖定,off鎖定
--log-bin-trust-function-creators=0|1
二進制日志打開時有效,該參數決定存儲函數創建者是否可以創建會導致不安全的時間記錄到二進制日志的存儲函數。當為0時,此時這也是默認值,除了擁有
super權限除了create routine或alter routine權限.同時也會強制函數必須和deterministic或reads
sql data又或者no sql的字符集一致.當設為1時MySQL不會去限制這些,這個變量同樣作用于觸發器
--sql-log-bin=0|1 當前session的sql是否記錄到binlog,擁有super權限用戶才可修改
--sync-
binlog=n在進行n次事務提交后,MySQL將執行一次磁盤同步指令講binlog文件的緩存寫到磁盤,當為0時MySQL總是講
binlog_cache寫到binlog文件,有fs來決定什么時候來同步到磁盤.該參數對MySQL性能有較大影響,簡朝陽
優與架構設計>中談到1和0兩個值之間性能能有5以上倍的差距
使用show status like "%bin%";的部分變量
Binlog_cache_disk_use 使用二進制日志緩存超過binlog_cache_size的值,被迫用臨時文件來保存事務中的語句的事務數量
Binlog_cache_use 二進制日志中經歷過事務的binlog緩存的數量
Replication中還以通過一下選項來減少binlog數據量,來達到提到效率的目的,前兩個用在Master端,后六個是用在Slave端的
--binlog-do-db二進制日志記錄的數據庫(多個數據庫用,分隔)
--binlog-ignore-db二進制日忽略的數據庫(多個數據庫用,分隔)
在replication的slave端還有一下6個參數
--replication-do-db設定需要復制的數據庫(多個數據庫用,分隔)
--replication-ignore-db設定忽略復制的數據庫(多個數據庫用,分隔)
--replication-do-table設定需要復制的表(多個表用,分隔)
--replication-ignore-table設定忽略復制的表(多個表用,分隔)
--replication-wild-do-table同replication-do-table功能一樣,但是可以加通配符
--replication-wild-ignore-table同replication-ignore-table功能一樣,但是可以加通配符
更多關于二進制說明查看最新版本官方英文手冊
總結
以上是生活随笔為你收集整理的mysql临时开启二进制_关于MySQL二进制日志Binlog的认识的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 上海欢乐谷最刺激的过山车
- 下一篇: mysql数据库表生成jpa注解_Ecl