MySQL的存儲引擎與日誌說明

時間  2019-11-17
標籤 mysql 存儲 引擎 日誌 說明 欄目 MySQL 简体版
原文   原文鏈接

1.1 存儲引擎的介紹

 

1.1.1 文件系統存儲

　　文件系統：操做系統組織和存取數據的一種機制。文件系統是一種軟件。html

　　類型：ext2 3 4 ，xfs 數據。  無論使用什麼文件系統，數據內容不會變化，不一樣的是，存儲空間、大小、速度。mysql

1.1.2 mysql數據庫存儲

　　MySQL引擎： 能夠理解爲，MySQL的「文件系統」，只不過功能更增強大。sql

　　MySQL引擎功能： 除了能夠提供基本的存取功能，還有更多功能事務功能、鎖定、備份和恢復、優化以及特殊功能。數據庫

1.1.3 MySQL存儲引擎種類

MySQL 提供如下存儲引擎：vim

InnoDB、MyISAM (最經常使用的兩種)
MEMORY、ARCHIVE、FEDERATED、EXAMPLE
BLACKHOLE、MERGE、NDBCLUSTER、CSV

　　除此以外還可使用第三方存儲引擎。緩存

1.1.4 innodb與myisam對比

InnoDb引擎安全

  1. 支持ACID的事務，支持事務的四種隔離級別；
  2. 支持行級鎖及外鍵約束：所以能夠支持寫併發；
  3. 不存儲總行數；
  4. 一個InnoDb引擎存儲在一個文件空間（共享表空間，表大小不受操做系統控制，一個表可能分佈在多個文件裏），也有可能爲多個（設置爲獨立表空，表大小受操做系統文件大小限制，通常爲2G），受操做系統文件大小的限制；
  5. 主鍵索引採用彙集索引（索引的數據域存儲數據文件自己），輔索引的數據域存儲主鍵的值；所以從輔索引查找數據，須要先經過輔索引找到主鍵值，再訪問輔索引；最好使用自增主鍵，防止插入數據時，爲維持B+樹結構，文件的大調整。

Innodb的主索引結構以下：服務器

 

MyISAM引擎併發

  1. 不支持事務，可是每次查詢都是原子的；
  2. 支持表級鎖，即每次操做是對整個表加鎖；
  3. 存儲表的總行數；
  4. 一個MYISAM表有三個文件：索引文件、表結構文件、數據文件；
  5. 採用菲彙集索引，索引文件的數據域存儲指向數據文件的指針。輔索引與主索引基本一致，可是輔索引不用保證惟一性。

MYISAM的主索引結構以下：oracle

 

兩種索引數據查找過程以下：

 

1.2 innodb存儲引擎

　　在MySQL5.5版本以後，默認的存儲引擎，提供高可靠性和高性能。

1.2.1 Innodb引擎的優勢

a)    事務安全（聽從ACID）
b)    MVCC（Multi-Versioning Concurrency Control，多版本併發控制）
c)    InnoDB行級鎖
d)    支持外鍵引用完整性約束
e)    出現故障後快速自動恢復（crash safe recovery）
f)    用於在內存中緩存數據和索引的緩衝區池（buffer pool（data buffer page  log buffer page） 、undo buffer page）
g)    大型數據捲上的最大性能
h)    將對錶的查詢與不一樣存儲引擎混合
i)    Oracle樣式一致非鎖定讀取(共享鎖)
j)    表數據進行整理來優化基於主鍵的查詢（彙集索引）

1.2.2 Innodb功能總覽

功能

支持

功能

支持

存儲限制

64 TB

索引高速緩存

是

MVCC

是

數據高速緩存

是

B 樹索引

是

自適應散列索引

是

羣集索引

是

複製

是

壓縮數據

是

更新數據字典

是

加密數據[b]

是

地理空間數據類型

是

查詢高速緩存

是

地理空間索引

否

事務

是

全文搜索索引

是

鎖定粒度

行

羣集數據庫

否

外鍵

是

備份和恢復

是

文件格式管理

是

快速索引建立

是

多個緩衝區池

是

PERFORMANCE_SCHEMA

是

更改緩衝

是

自動故障恢復

是

1.2.3 查詢存儲引擎的方法

一、使用 SELECT 確認會話存儲引擎：

SELECT @@default_storage_engine;
或
show variables like '%engine%';

二、使用 SHOW 確認每一個表的存儲引擎：

SHOW CREATE TABLE City\G
SHOW TABLE STATUS LIKE 'CountryLanguage'\G

三、使用 INFORMATION_SCHEMA 確認每一個表的存儲引擎：

SELECT TABLE_NAME, ENGINE FROM 
INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'City'
AND TABLE_SCHEMA = 'world_innodb'\G

四、從5.1版本，遷移到5.5版本以上版本

   　　假如5.1版本數據庫全部生產表都是myisam的。

  　　 使用mysqldump備份後，一點要替換備份的文件中的engine(引擎)字段，從myisam替換爲innodb（可使用sed命令），不然遷移無任何意義。

  　　 數據庫升級時，要注意其餘配套設施的兼容性，注意代碼可否兼容新特性。

1.2.4 設置存儲引擎

一、在啓動配置文件中設置服務器存儲引擎：

[mysqld]
default-storage-engine=<Storage Engine>

二、使用 SET 命令爲當前客戶機會話設置：

SET @@storage_engine=<Storage Engine>;

三、在 CREATE TABLE 語句指定：

CREATE TABLE t (i INT) ENGINE = <Storage Engine>;

1.3 InnoDB存儲引擎的存儲結構

1.3.1 InnoDB 系統表空間特性

  1. 默認狀況下，InnoDB 元數據、撤消日誌和緩衝區存儲在系統「表空間」中。
  2. 這是單個邏輯存儲區域，能夠包含一個或多個文件。
  3. 每一個文件能夠是常規文件或原始分區。
  4. 最後的文件能夠自動擴展。

1.3.2 表空間的定義

　　表空間：MySQL數據庫存儲的方式

　　　　表空間中包含數據文件

　　MySQl表空間和數據文件是1:1的關係

　　　　共享表空間除外，是能夠1:N關係

 

1.3.3 表空間類型

　　一、共享表空間：ibdata1~ibdataN,通常是2-3個

　　二、獨立表空間：存放在指定庫目錄下，例如data/world/目錄下的city.ibd

　　　　表空間位置（datadir）：

　　　　data/目錄下

1.3.4 系統表空間的存儲內容

共享表空間（物理存儲結構）

  　　 ibdata1~N 一般被叫作系統表空間，是數據初始化生成的

  　　 系統元數據，基表數據，除了表內容數據以外的數據。

   　　tmp 表空間（通常不多關注）

   　　undo日誌 ：數據--回滾數據（回滾日誌使用）

  　　 redo日誌 ：ib_logfile0~N 存放系統的innodb表的一些重作日誌。

  　　 說明：undo日誌默認實在ibdata中的，在5.6之後是能夠單獨定義的。

       　　 tmp 表空間在5.7版本以後被移出了ibdata1，變爲ibtmp1

      　　  在5.5版本以前，全部的應用數據也都默認存放到了ibdata中。

獨立表空間(一個存儲引擎的功能)

  　　 在5.6以後，默認的狀況下會單表單獨存儲到獨立表空間文件

　　　除了系統表空間以外，InnoDB 還在數據庫目錄中建立另外的表空間，用於每一個 InnoDB 表的 .ibd 文件。

　　   InnoDB 建立的每一個新表在數據庫目錄中設置一個 .ibd 文件來搭配表的.frm 文件。

　　　可使用 innodb_file_per_table 選項控制此設置，更改該設置僅會更改已建立的新表的默認值。。

 

1.3.5 設置共享表空間

查看當前的共享表空間設置

mysql> show variables like 'innodb_data_file_path';
+-----------------------+------------------------+
| Variable_name         | Value                  |
+-----------------------+------------------------+
| innodb_data_file_path | ibdata1:12M:autoextend |
+-----------------------+------------------------+
1 row in set (0.00 sec)

　設置共享表空間：

　　通常是在初始搭建環境的時候就配置號，預設值通常爲1G；且最後一個爲自動擴展。

[root@db02 world]# vim /etc/my.cnf
[mysqld]
innodb_data_file_path=ibdata1:76M;ibdata2:100M:autoextend

重啓服務查看當前的共享表空間設置

mysql> show variables like 'innodb_data_file_path';
+-----------------------+-------------------------------------+
| Variable_name         | Value                               |
+-----------------------+-------------------------------------+
| innodb_data_file_path | ibdata1:76M;ibdata2:100M:autoextend |
+-----------------------+-------------------------------------+
1 row in set (0.00 sec)

1.3.6 設置獨立表空間

　　　獨立表空間在5.6版本是默認開啓的。

　　　獨立表空間注意事項：不開起獨立表空間，共享表空間會佔用很大

mysql> show variables like '%per_table%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+
1 row in set (0.00 sec)

   在參數文件/etc/my.cnf  能夠控制獨立表空間

關閉獨立表空間 （0是關閉，1是開啓）

[root@db02 clsn]# vim /etc/my.cnf
[mysqld]
innodb_file_per_table=0

查看獨立表空間配置

mysql> show variables like '%per_table%' ;
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF   |
+-----------------------+-------+
1 row in set (0.00 sec)

小結:

innodb_file_per_table=0    關閉獨立表空間
innodb_file_per_table=1    開啓獨立表空間，單表單存儲

1.4 MySQL中的事務

　　一組數據操做執行步驟，這些步驟被視爲一個工做單元

  　　　　 用於對多個語句進行分組，能夠在多個客戶機併發訪問同一個表中的數據時使用。

　　全部步驟都成功或都失敗

  　　　　 若是全部步驟正常，則執行，若是步驟出現錯誤或不完整，則取消。

簡單來講事務就是：保證工做單元中的語句同時成功或同時失敗。

 

事務處理流程示意圖

1.4.1 事務是什麼

　　與其給事務定義，不如說一說事務的特性。衆所周知，事務須要知足ACID四個特性。

A(atomicity) 原子性。

　　　一個事務的執行被視爲一個不可分割的最小單元。事務裏面的操做，要麼所有成功執行，要麼所有失敗回滾，不能夠只執行其中的一部分。

全部語句做爲一個單元所有成功執行或所有取消。
updata t1 set money=10000-17 where  id=wxid1
updata t1 set money=10000+17  where  id=wxid2

C(consistency) 一致性。

　　一個事務的執行不該該破壞數據庫的完整性約束。若是上述例子中第2個操做執行後系統崩潰，保證A和B的金錢總計是不會變的。

若是數據庫在事務開始時處於一致狀態，則在執行該事務期間將保留一致狀態。
    updata t1 set money=10000-17 where  id=wxid1
    updata t1 set money=10000+17  where  id=wxid2
    在以上操做過程當中，去查本身帳戶仍是10000

I(isolation) 隔離性。

　　一般來講，事務之間的行爲不該該互相影響。然而實際狀況中，事務相互影響的程度受到隔離級別的影響。文章後面會詳述。

　　事務之間不相互影響。在作操做的時候，其餘人對這兩個帳戶作任何操做，在不一樣的隔離條件下，可能一致性保證又不同

隔離級別

    隔離級別會影響到一致性。
    read-uncommit  X
    read-commit   可能會用的一種級別
    repeatable-read   默認的級別，和oracle同樣的
    SERIALIZABLE       嚴格的默認，通常不會用

　　此規則除了受隔離級別控制，還受鎖控制，能夠聯想一下NFS的實現

D(durability) 持久性。

　　事務提交以後，須要將提交的事務持久化到磁盤。即便系統崩潰，提交的數據也不該該丟失。

　保證數據落地，纔算事務真正安全

1.4.2 事務的控制語句

經常使用的事務控制語句：

    START TRANSACTION（或 BEGIN）：顯式開始一個新事務
    COMMIT：永久記錄當前事務所作的更改(事務成功結束)
    ROLLBACK：取消當前事務所作的更改(事務失敗結束)

須要知道的事務控制語句：

    SAVEPOINT：分配事務過程當中的一個位置，以供未來引用
    ROLLBACK TO SAVEPOINT：取消在 savepoint 以後執行的更改
    RELEASE SAVEPOINT：刪除 savepoint 標識符
    SET AUTOCOMMIT：爲當前鏈接禁用或啓用默認 autocommit模式

1.4.3 autocommit參數

　　在MySQL5.5開始，開啓事務時再也不須要begin或者start transaction語句。而且，默認是開啓了Autocommit模式，做爲一個事務隱式提交每一個語句。

　　在有些業務繁忙企業場景下，這種配置可能會對性能產生很大影響，但對於安全性上有很大提升。未來，咱們須要去權衡咱們的業務需求去調整是否自動提交。

　　注意：在生產中，根據實際需求選擇是否可開啓，通常銀行類業務會選擇關閉。

查看當前autocommit狀態：

mysql> show variables like '%autoc%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.00 sec)

修改配置文件，並重啓

[root@db02 world]# vim /etc/my.cnf
[mysqld]
autocommit=0

再次查看autocommit狀態

mysql> show variables like '%autoc%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | OFF   |
+---------------+-------+
1 row in set (0.00 sec)
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)

　　說明： autocommit設置爲開啓的對比

   　　 優勢：數據安全性好，每次修改都會落地

  　　  缺點：不能進行銀行類的交易事務、產生大量小的IO

1.4.4 致使提交的非事務語句：

DDL語句： （ALTER、CREATE 和 DROP）
DCL語句： （GRANT、REVOKE 和 SET PASSWORD）
鎖定語句：（LOCK TABLES 和 UNLOCK TABLES）

致使隱式提交的語句示例：

TRUNCATE TABLE
LOAD DATA INFILE
SELECT FOR UPDATE

用於隱式提交的 SQL 語句：

START TRANSACTION
SET AUTOCOMMIT = 1

1.5 redo與undo

 

1.5.1 事務日誌undo

undo原理：

　　Undo Log的原理很簡單，爲了知足事務的原子性，在操做任何數據以前，首先將數據備份到一個地方（這個存儲數據備份的地方稱爲Undo Log）。而後進行數據的修改。

　　若是出現了錯誤或者用戶執行了ROLLBACK語句，系統能夠利用Undo Log中的備份將數據恢復到事務開始以前的狀態。

除了能夠保證事務的原子性，Undo Log也能夠用來輔助完成事務的持久化。

 

undo是什麼？

　　undo,顧名思義「回滾日誌」，是事務日誌的一種。

做用是什麼？

　　在事務ACID過程當中，實現的是「A「原子性的做用。

用Undo Log實現原子性和持久化的事務的簡化過程

  假設有A、B兩個數據，值分別爲1,2。
  A.事務開始.
  B.記錄A=1到undo log.
  C.修改A=3.
  D.記錄B=2到undo log.
  E.修改B=4.
  F.將undo log寫到磁盤。
  G.將數據寫到磁盤。
  H.事務提交

  這裏有一個隱含的前提條件：‘數據都是先讀到內存中，而後修改內存中的數據，最後將數據寫回磁盤之因此能同時保證原子性和持久化，是由於如下特色：

  A. 更新數據前記錄Undo log。
  B. 爲了保證持久性，必須將數據在事務提交前寫到磁盤。只要事務成功提交，數據必然已經持久化。
  C. Undo log必須先於數據持久化到磁盤。若是在G,H之間系統崩潰，undo log是完整的，能夠用來回滾事務。
  D. 若是在A-F之間系統崩潰,由於數據沒有持久化到磁盤。因此磁盤上的數據仍是保持在事務開始前的狀態。

缺陷：

　　每一個事務提交前將數據和Undo Log寫入磁盤，這樣會致使大量的磁盤IO，所以性能很低。若是可以將數據緩存一段時間，就能減小IO提升性能。可是這樣就會喪失事務的持久性。

　　所以引入了另一種機制來實現持久化，即Redo Log.

1.5.2 事務日誌redo

redo原理：

　　和Undo Log相反，Redo Log記錄的是新數據的備份。在事務提交前，只要將Redo Log持久化便可，不須要將數據持久化。當系統崩潰時，雖然數據沒有持久化，可是Redo Log已經持久化。

　　系統能夠根據Redo Log的內容，將全部數據恢復到最新的狀態。

 

 

Redo是什麼？

　　redo,顧名思義「重作日誌」，是事務日誌的一種。

做用是什麼？

　　在事務ACID過程當中，實現的是「D」持久化的做用。

Undo + Redo事務的簡化過程

 假設有A、B兩個數據，值分別爲1,2.
  A.事務開始.
  B.記錄A=1到undo log.
  C.修改A=3.
  D.記錄A=3到redo log.
  E.記錄B=2到undo log.
  F.修改B=4.
  G.記錄B=4到redo log.
  H.將redo log寫入磁盤。
  I.事務提交

Undo + Redo事務的特色

 A. 爲了保證持久性，必須在事務提交前將Redo Log持久化。
  B. 數據不須要在事務提交前寫入磁盤，而是緩存在內存中。
  C. Redo Log 保證事務的持久性。
  D. Undo Log 保證事務的原子性。
  E. 有一個隱含的特色，數據必需要晚於redo log寫入持久存儲。

redo是否持久化到磁盤參數

innodb_flush_log_at_trx_commit=1/0/2

1.5.3 事務中的鎖

什麼是「鎖」？

　　「鎖」顧名思義就是鎖定的意思。

「鎖」的做用是什麼？

　　在事務ACID過程當中，「鎖」和「隔離級別」一塊兒來實現「I」隔離性的做用。

 

鎖的粒度：

　　一、MyIasm：低併發鎖——表級鎖

　　二、Innodb：高併發鎖——行級鎖

四種隔離級別：

READ UNCOMMITTED 許事務查看其餘事務所進行的未提交更改
READ COMMITTED    容許事務查看其餘事務所進行的已提交更改
REPEATABLE READ****** 確保每一個事務的 SELECT 輸出一致； InnoDB 的默認級別
SERIALIZABLE  將一個事務的結果與其餘事務徹底隔離

開銷、加鎖速度、死鎖、粒度、併發性能

表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的機率最高,併發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的機率最低,併發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度通常。

　　從上述特色可見，很難籠統地說哪一種鎖更好，只能就具體應用的特色來講哪一種鎖更合適！

　　僅從鎖的角度來講：表級鎖更適合於以查詢爲主，只有少許按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件併發更新少許不一樣數據，同時又有併發查詢的應用，如一些在線事務處理（OLTP）系統。

1.6 MySQL 日誌管理

1.6.1 MySQL日誌類型簡介

日誌的類型的說明：

日誌文件

選項

文件名

程序

N/A

表名稱

錯誤

--log-error

host_name.err

N/A

常規

--general_log

host_name.log

mysqldumpslow

mysqlbinlog

general_log

慢速查詢

--slow_query_log

--long_query_time

host_name-slow.log

N/A

程序

slow_log

二進制

--log-bin

--expire-logs-days

host_name-bin.000001

N/A

審計

--audit_log

--audit_log_file

audit.log

N/A

 

1.6.2 配置方法

狀態錯誤日誌：

[mysqld]
log-error=/data/mysql/mysql.log

查看配置方式：

mysql> show variables like '%log%error%';

做用：

　　記錄mysql數據庫的通常狀態信息及報錯信息，是咱們對於數

　據庫常規報錯處理的經常使用日誌。

mysql> show variables  like '%log%err%';
+---------------------+----------------------------------+
| Variable_name       | Value                            |
+---------------------+----------------------------------+
| binlog_error_action | IGNORE_ERROR                     |
| log_error           | /application/mysql/data/db02.err |
+---------------------+----------------------------------+
2 rows in set (0.00 sec)

1.6.3 通常查詢日誌

配置方法:

[mysqld]
general_log=on
general_log_file=/data/mysql/server2.log

查看配置方式：

show variables like '%gen%';

做用：

　　記錄mysql全部執行成功的SQL語句信息，能夠作審計用，可是咱們不多開啓

mysql> show variables like '%gen%';
+------------------+----------------------------------+
| Variable_name    | Value                            |
+------------------+----------------------------------+
| general_log      | OFF                              |
| general_log_file | /application/mysql/data/db02.log |
+------------------+----------------------------------+
2 rows in set (0.00 sec)

1.7 二進制日誌

　　二進制日誌不依賴與存儲引擎的。

　　依賴於sql層，記錄和sql語句相關的信息

binlog日誌做用：

  　　 一、提供備份功能

  　　 二、進行主從複製

 　　  三、基於時間點的任意恢復

　　記錄在sql層已經執行完成的語句，若是是事務，則記錄已完成的事務。

　　功能做用： 時間點備份 和 時間點恢復、 主從

二進制日誌的「總閘」

做用：

1、是否開啓
2、二進制日誌路徑/data/mysql/
3、二進制日誌文件名前綴mysql-bin  
4、文件名以"前綴".000001~N
log-bin=/data/mysql/mysql-bin

二進制日誌的「分開關」：

只有總閘開啓纔有意義，默認是開啓狀態。
咱們在有些時候會臨時關閉掉。
隻影響當前會話。
sql_log_bin=1/0

1.7.1 二進制日誌的格式

statement，語句模式：

記錄信息簡潔，記錄的是SQL語句自己。可是在語句中出現函數操做的話，有可能記錄的數據不許確。
5.6中默認模式，但生產環境中慎用，建議改爲row。

row，行模式

表中行數據的變化過程。
記錄數據詳細，對IO性能要求比較高
記錄數據在任何狀況下都是準確的。
生產中通常是這種模式。
5.7之後默認的模式。

mixed，混合模式

通過判斷，選擇row+statement混合的一種記錄模式。（通常不用）

1.7.2 開啓二進制日誌

mysql> show variables like '%log_bin%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| log_bin                         | OFF   |
| log_bin_basename                |       |
| log_bin_index                   |       |
| log_bin_trust_function_creators | OFF   |
| log_bin_use_v1_row_events       | OFF   |
| sql_log_bin                     | ON    |
+---------------------------------+-------+
6 rows in set (0.00 sec)

修改配置文件開啓二進制日誌

[root@db02 tmp]# vim /etc/my.cnf
[mysqld]
log-bin=/application/mysql/data/mysql-bin

命令行修改的方法

mysql> SET GLOBAL binlog_format = 'STATEMENT'
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

查看文件二進制日誌的類型

[root@db02 data]# file mysql-bin.*
mysql-bin.000001: MySQL replication log
mysql-bin.index:  ASCII text

查看MySQL的配置：

mysql> show variables like '%log_bin%';
+---------------------------------+-----------------------------------------+
| Variable_name                   | Value                                   |
+---------------------------------+-----------------------------------------+
| log_bin                         | ON                                      |
| log_bin_basename                | /application/mysql/data/mysql-bin       |
| log_bin_index                   | /application/mysql/data/mysql-bin.index |
| log_bin_trust_function_creators | OFF                                     |
| log_bin_use_v1_row_events       | OFF                                     |
| sql_log_bin                     | ON                                      |
+---------------------------------+-----------------------------------------+
6 rows in set (0.00 sec)

1.7.3 定義記錄方式

查看如今的格式

mysql> show variables like '%format%';
+--------------------------+-------------------+
| Variable_name            | Value             |
+--------------------------+-------------------+
| binlog_format            | STATEMENT         |
| date_format              | %Y-%m-%d          |
| datetime_format          | %Y-%m-%d %H:%i:%s |
| default_week_format      | 0                 |
| innodb_file_format       | Antelope          |
| innodb_file_format_check | ON                |
| innodb_file_format_max   | Antelope          |
| time_format              | %H:%i:%s          |
+--------------------------+-------------------+
8 rows in set (0.00 sec)

修改格式

[root@db02 data]# vim /etc/my.cnf
[mysqld]
binlog_format=row

改完以後查看

mysql> show variables like '%format%';
+--------------------------+-------------------+
| Variable_name            | Value             |
+--------------------------+-------------------+
| binlog_format            | ROW               |
| date_format              | %Y-%m-%d          |
| datetime_format          | %Y-%m-%d %H:%i:%s |
| default_week_format      | 0                 |
| innodb_file_format       | Antelope          |
| innodb_file_format_check | ON                |
| innodb_file_format_max   | Antelope          |
| time_format              | %H:%i:%s          |
+--------------------------+-------------------+
8 rows in set (0.00 sec)

1.8 二進制日誌的操做

1.8.1 查看

  操做系統層面查看

[root@db02 data]# ll mysql-bin.*
-rw-rw---- 1 mysql mysql 143 Dec 20 20:17 mysql-bin.000001
-rw-rw---- 1 mysql mysql 120 Dec 20 20:17 mysql-bin.000002
-rw-rw---- 1 mysql mysql  82 Dec 20 20:17 mysql-bin.index

刷新日誌

mysql> flush logs;

刷新完成後的日誌目錄

[root@db02 data]# ll mysql-bin.*
-rw-rw---- 1 mysql mysql 143 Dec 20 20:17 mysql-bin.000001
-rw-rw---- 1 mysql mysql 167 Dec 20 20:24 mysql-bin.000002
-rw-rw---- 1 mysql mysql 120 Dec 20 20:24 mysql-bin.000003
-rw-rw---- 1 mysql mysql 123 Dec 20 20:24 mysql-bin.index
[root@db02 data]#

查看當前使用的二進制日誌文件

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      120 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

查看全部的二進制日誌文件

mysql> show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       143 |
| mysql-bin.000002 |       167 |
| mysql-bin.000003 |       120 |
+------------------+-----------+
3 rows in set (0.00 sec) 

1.8.2 查看二進制日誌內容

名詞說明：

　　一、events 事件

      　　　二進制日誌如何定義：命令的最小發生單元

　　二、position

  　　　　 每一個事件在整個二進制文件中想對應的位置號就是position號

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      120 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
[root@db02 data]# mysqlbinlog  mysql-bin.000003 >/tmp/aa.ttt

導出全部的信息

[root@db02 data]# mysqlbinlog  mysql-bin.000003 >/tmp/aa.ttt

binlog的查看方式：

一、查看binlog原始信息

mysqbin   mysql-bin.000002

二、在row模式下，翻譯成語句

mysqlbinlog --base64-output='decode-rows' -v   mysql-bin.000002

三、查看binlog事件

show binary logs; 全部在使用的binlog信息
show binlog events in '日誌文件'

4、如何截取binlog內容，按需求恢復（常規思路）

　　（1）、show binary logs;   show master status;

　　（2）、show binlog events in '' 從後往前看，找到誤操做的事務，判斷事務開始position和結束position

　　（3）、把誤操做的剔除掉，留下正常操做到2個sql文件中

　　（4）、先測試庫恢復，把誤操做的數據導出，而後生產恢復。

使用上述方法遇到的問題：

 　　 恢復事件較長

  　　　　對生產數據有必定的影響，有可能會出現冗餘數據

　較好的解決方案。

　　　　一、flashback閃回功能

　　　　二、經過備份，延時從庫

1.8.3 mysqlbinlog截取二進制日誌的方法

mysqlbinlog常見的選項有如下幾個：

 

參數

參數說明

--start-datetime

從二進制日誌中讀取指定等於時間戳或者晚於本地計算機的時間

--stop-datetime

從二進制日誌中讀取指定小於時間戳或者等於本地計算機的時間取值和上述同樣

--start-position

從二進制日誌中讀取指定position 事件位置做爲開始。

--stop-position

從二進制日誌中讀取指定position 事件位置做爲事件截至

  二進制日誌文件示例：  mysqlbinlog --start-position=120 --stop-position=結束號  

1.8.4 刪除二進制日誌

　　默認狀況下，不會刪除舊的日誌文件。

根據存在時間刪除日誌：

SET GLOBAL expire_logs_days = 7;
或
PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;

根據文件名刪除日誌：

PURGE BINARY LOGS TO 'mysql-bin.000010';

   重置二進制日誌計數，從1開始計數，刪除原有的二進制日誌。

reset master

1.9 mysql的慢查詢日誌（slow log）

1.9.1 這是什麼呢？

　　slow-log  記錄全部條件內的慢的sql語句

  　 優化的一種工具日誌。可以幫咱們定位問題。

1.9.2 慢查詢日誌

　　是將mysql服務器中影響數據庫性能的相關SQL語句記錄到日誌文件

　　經過對這些特殊的SQL語句分析，改進以達到提升數據庫性能的目的。慢日誌設置

long_query_time ： 設定慢查詢的閥值，超出次設定值的SQL即被記錄到慢查詢日誌，缺省值爲10s
slow_query_log ： 指定是否開啓慢查詢日誌
slow_query_log_file ： 指定慢日誌文件存放位置，能夠爲空，系統會給一個缺省的文件host_name-slow.log
min_examined_row_limit：查詢檢查返回少於該參數指定行的SQL不被記錄到慢查詢日誌
log_queries_not_using_indexes: 不使用索引的慢查詢日誌是否記錄到索引

慢查詢日誌配置

[root@db02 htdocs]# vim /etc/my.cnf
slow_query_log=ON
slow_query_log_file=/tmp/slow.log
long_query_time=0.5    # 控制慢日誌記錄的閾值
log_queries_not_using_indexes

      配置完成後重啓服務...

查看慢查詢日誌是否開啓，及其位置。

mysql> show variables like '%slow%'
    -> ;
+---------------------------+---------------+
| Variable_name             | Value         |
+---------------------------+---------------+
| log_slow_admin_statements | OFF           |
| log_slow_slave_statements | OFF           |
| slow_launch_time          | 2             |
| slow_query_log            | ON            |
| slow_query_log_file       | /tmp/slow.log |
+---------------------------+---------------+
5 rows in set (0.00 sec)

1.9.3 mysqldumpslow命令

　/path/mysqldumpslow -s c -t 10 /database/mysql/slow-log

這會輸出記錄次數最多的10條SQL語句，其中：

參數

說明

-s

是表示按照何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢

時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒敘；

-t

是top n的意思，即爲返回前面多少條的數據；

-g

後邊能夠寫一個正則匹配模式，大小寫不敏感的；

例子：

/path/mysqldumpslow -s r -t 10 /database/mysql/slow-log

獲得返回記錄集最多的10個查詢。

/path/mysqldumpslow -s t -t 10 -g 「left

join」/database/mysql/slow-log

獲得按照時間排序的前10條裏面含有左鏈接的查詢語句。

1.9.4 怎麼保證binlog和redolog已提交事務的一致性

　　在沒有開啓binlog的時候，在執行commit，認爲redo日誌持久化到磁盤文件中，commit命令就成功。

寫binlog參數：

mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 0     |    #控制binlog commit 階段
+---------------+-------+
1 row in set (0.00 sec)

   sync_binlog 確保是否每一個提交的事務都寫到binlog中。

1.9.5 mysql中的雙一標準：

　　innodb_flush_log_at_trx_commit和sync_binlog 兩個參數是控制MySQL 磁盤寫入策略以及數據安全性的關鍵參數。

參數意義說明：

innodb_flush_log_at_trx_commit=1

　　若是innodb_flush_log_at_trx_commit設置爲0，log buffer將每秒一次地寫入log file中，而且log file的flush(刷到磁盤)操做同時進行.該模式下，在事務提交的時候，不會主動觸發寫入磁盤的操做。

　　若是innodb_flush_log_at_trx_commit設置爲1，每次事務提交時MySQL都會把log buffer的數據寫入log file，而且flush(刷到磁盤)中去.

　　若是innodb_flush_log_at_trx_commit設置爲2，每次事務提交時MySQL都會把log buffer的數據寫入log file.可是flush(刷到磁盤)操做並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁盤)操做。

注意：

因爲進程調度策略問題,這個「每秒執行一次 flush(刷到磁盤)操做」並非保證100%的「每秒」。

參數意義說明：

 　　sync_binlog=1 

　　sync_binlog 的默認值是0，像操做系統刷其餘文件的機制同樣，MySQL不會同步到磁盤中去而是依賴操做系統來刷新binary log。

　　當sync_binlog =N (N>0) ，MySQL 在每寫 N次 二進制日誌binary log時，會使用fdatasync()函數將它的寫二進制日誌binary log同步到磁盤中去。

注:

　　若是啓用了autocommit，那麼每個語句statement就會有一次寫操做；不然每一個事務對應一個寫操做。

安全方面說明

　　當innodb_flush_log_at_trx_commit和sync_binlog 都爲 1 時是最安全的，在mysqld 服務崩潰或者服務器主機crash的狀況下，binary log 只有可能丟失最多一個語句或者一個事務。可是魚與熊掌不可兼得，雙11 會致使頻繁的io操做，所以該模式也是最慢的一種方式。

　　當innodb_flush_log_at_trx_commit設置爲0，mysqld進程的崩潰會致使上一秒鐘全部事務數據的丟失。

　　當innodb_flush_log_at_trx_commit設置爲2，只有在操做系統崩潰或者系統掉電的狀況下，上一秒鐘全部事務數據纔可能丟失。

　　雙1適合數據安全性要求很是高，並且磁盤IO寫能力足夠支持業務，好比訂單,交易,充值,支付消費系統。雙1模式下，當磁盤IO沒法知足業務需求時 好比11.11 活動的壓力。推薦的作法是 innodb_flush_log_at_trx_commit=2 ，sync_binlog=N (N爲500 或1000) 且使用帶蓄電池後備電源的緩存cache，防止系統斷電異常。

　　系統性能和數據安全是業務系統高可用穩定的必要因素。咱們對系統的優化須要尋找一個平衡點，合適的纔是最好的，根據不一樣的業務場景需求，能夠將兩個參數作組合調整，以即是db系統的性能達到最優化。

1.10 參考文獻

https://www.cnblogs.com/wangdake-qq/p/7358322.html
http://www.jb51.net/article/87653.htm
http://www.mysqlops.com/2012/04/06/innodb-log1.html
https://www.cnblogs.com/Bozh/archive/2013/03/18/2966494.html
https://www.cnblogs.com/andy6/p/6626848.html
https://www.cnblogs.com/xuanzhi201111/p/4128894.html  Anemometer實現pt-query-digest 圖形化
http://www.coooz.com/archives/771         雙一標準
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程