第22章，mysql數據庫-2

時間 2021-04-08

標籤 html 前端 node mysql c++ git github web sql shell 欄目 MySQL 简体版

原文原文鏈接

第22章，mysql數據庫-2html

本章內容：前端

MYSQL 用戶和權限管理node

服務器變量和SQL_MODEmysql

查詢緩存c++

索引git

併發控制和事務github

mysql日誌功能web

mysql備份和恢復sql

主從複製和高可用shell

壓力測試

mysql生產環境配置實例

MYSQL 用戶和權限管理：--------------------------------------------------------

元數據數據庫：mysql

系統受權表：

db，host，user

columns_priv,tables_priv,procs_priv,proxies_priv

用戶建立：

CREATE USER 'user_name'@'host' [IDENTIFIED BY 'password']

默認權限：USAGE

用戶重命名：

RENAME USER old_user_name TO new_name

刪除用戶：

DROP USER 'USERNAME'@'HOST'

修改密碼：

1 SET PASSWORD FOR 'username'@'host'=PASSWORD('password')

即時生效，=先後帶不帶' '都行

2 UPDATE mysql.user SET password=PASSWORD('password') WHERE ...;

須要刷新權限以後生效

FLUSH PRIVILEGES;

3 #mysqladmin -u root -p'oldpassword' password 'newpass'

shell 命令行修改管理員密碼

忘記管理員密碼的解決辦法：

1 vim /etc/my.cnf

[mysqld]

skip-grant-tables=ON

skip-networking=ON

2 systemctl restart mysqld

mysql

UPDATE mysql.user SET password=PASSWORD('password') WHERE user='root';

FLUSH PRIVILEGES;

EXIT

3 vim /etc/my.cnf

刪除skip-grant-tables=ON skip-networking=ON

重啓服務

4 使用新密碼登陸root

MYSQL 權限管理：

權限類別：

管理類：

CREATE TEMPORARY TABLES

CREATE USER

FILE

SUPER

SHOW DATABASES

RELOAD

SHUTDOWN

REPLICATION SLAVE

REPLICATION CLIENT

LOCK TABLES

程序類：FUNCTION,PROCEDURE,TRIGGER

CREATE

ALTER

DROP

EXCUTE

庫和表級別：DATABASE,TABLE

ALTER

CREATE

CREATE VIEW

DROP

INDEX

SHOW VIEW

GRANT OPTION: 能將本身得到的權限轉贈給其餘用戶，慎用

數據操做：

SELECT

INSERT

DELETE

UPDATE

字段級別：

SELECT(col1,col2,..)

UPDATE(col1,col2,..)

INSERT(col1,col2,..)

全部權限：ALL PRIVILEGES 或 ALL

受權：GRANT

受權：

GRANT priv_type[(column_list)].. ON [object_type] priv_level

TO 'user'@'host'

[IDENTIFIED BY PASSWORD('password')] [WITH GRANT OPTION];

選項介紹：

priv_type: ALL[PRIVILEGES]

object_type: TABLE|FUNCTION |PROCEDURE

priv_level: *（全部庫）|*.*|db_name.*|db_name.tb_name|

tb_name(當前庫的表)|db_name.routine_name(指定庫的函數，存儲過程，觸發器)

with_option: GRANT OPTION

MAX_QUERIES_PER_HOUR count 每小時最大訪問

MAX_UPDATES_PER_HOUR count

MAX_CONNECTIONS_PER_HOUR count

MAX_USER_CONNECTIONS count

示例：

GRANT SELECT,INSERT,UPDATE(stuid,name,age) ON hellodb.students TO 'wang'@'%';

GRANT ALL ON hellodb.students TO user1@'%' IDENTIFIED BY PASSWORD('centos');

回收權限：

REVOKE priv_type[(column_list)][,priv_type(col_list)]...

ON [object_type] priv_level FROM 'user'@'host';

示例：

REVOKE ALL ON laa.* FROM 'wang'@'%'

查看指定用戶得到的受權：

SHOW GRANTS FOR 'user'@'host';

SHOW GRANTS FOR CURRENT_USER[()];

注意：

1 mariaDB服務進程啓動時會讀取mysql庫中全部受權表至內存

2 GRANT 或 REVOKE 等執行權限操做會保存於系統表中，mariadb的服務進程

一般會自動重讀受權表，使之生效

3 對於不可以或不能及時重讀受權表的命令，可手動讓mariadb的服務進程重讀受權表

FLUSH PRIVILEGES;

MYSQL中的系統數據庫：

mysql數據庫：

是mysql的核心數據庫，相似於sql server中的master庫，主要負責存儲數據庫

的用戶，權限設置，關鍵字等mysql本身須要使用的控制和管理信息

performance_schema:

MYSQL5.5開始新增的數據庫，主要用於收集數據庫服務器性能參數，庫裏表

的存儲引擎均爲PERFORMANCE_SCHEMA,用戶不能建立存儲引擎爲PERFORMANCE_SCHEMA的表

information_schema:

MYSQL5.0以後產生的，一個虛擬數據庫，物理上並不存在。information_schema

數據庫相似與’數據字典‘，提供了訪問數據庫元數據的方式，即數據的數據。

好比數據庫名或表名，列類型，訪問權限更加細化的訪問方式）

服務器配置：

mysqld選項，服務器系統變量和服務器狀態變量

官方文檔地址

https://dev.mysql.com/doc/refman/5.7/en/server-option-variable-reference.html

https://mariadb.com/kb/en/library/full-list-of-mariadb-options-system-and-status-variables/

注意：其中有些參數支持運行時修改，會當即生效

有些參數不支持，且只能經過修改配置文件，並重啓服務器程序生效

有些參數做用域是全局的，且不可改變，有些能夠爲每一個用戶提供單獨設置（會話級別）

獲取mysqld的可用選項列表：

mysqld --help --verbose

mysqld --print-defaults 當前默認服務器配置

服務器系統變量：分全局和會話兩種

服務器狀態變量：分全局和會話兩種

獲取運行中的mysql進程使用各服務器參數及其值：

SHOW GLOBAL VARIABLES [LIKE ''];

SHOW [SESSION] VARIABLES [LIKE ''];

設置服務器系統變量的三種方法：

1 在shell命令行設置：

./mysqld_safe --skip-name-resolve=1

2 在配置文件my.cnf中設置

skip_name_resolve=1

3 在mysql客戶端使用SET命令

SET [GLOBAL] sql_log_bin=0;

修改服務器變量的值：

help SET;

修改全局變量：僅對修改後心建立的會話有效，對已經創建的會話無效

SET GLOBAL system_var_name=value;

SET @@.global.system_var_name=value;

修改會話變量：

SET [SESSION] system_var_name=value;

SET @@[session.]system_var_name=value;

狀態變量（只讀）：用於保存mysql運行中的統計數據的變量，不可更改

SHOW GLOBAL STATUS;

SHOW [SESSION] STATUS;

服務器變量SQL_MODE

SQL_MODE：對其設置能夠完成一些約束檢查的工做，可分別進行全局的設置或當前

會話的設置，

參看：https://mariadb.com/kb/en/library/sql-mode/

如設置：

SET SET SQL_MODE='traditional'

常見mode：

NO_AUTO_CREATE_USER

禁止GRANT建立密碼爲空的用戶

NO_AUTO_VALUE_ON_ZERO

在自增加的列中插入0或NULL將不會是下一個自增加值

NO_BACKSLASH_ESCAPES

反斜槓'\'做爲普通字符而非轉義字符

PAD_CHAR_TO_FULL_LENGTH

啓用後，對於CHAR類型將不會截斷空洞數據

PIPES_AS_CONCAT

將"||"視爲鏈接操做符而非"或運算符

查詢緩存：---------------------------------------------------------------------

查詢指令的執行過程：

客戶端指令 ---> mysql server ---> 查詢緩存，若是有匹配直接返回結果

若是沒有匹配項

---> 解析器 --- 生成解析樹 ---> 預處理器 ---> 解析樹

---> 查詢優化器，有可能改寫查詢語句 ---> 生成查詢執行計劃

---> 查詢執行引擎，執行指令 ---> API調用 ---> 存儲引擎 ---> 讀取數據

---> 返回查詢結果，而且將結果放入查詢緩存之中

查詢緩存（query cache）原理：

緩存SELECT操做或預處理查詢的結果集和SQL語句，當有新的SELECT語句或預處理查詢

語句請求，先去查詢緩存，判斷是否存在可用的記錄集

判斷標準：

與緩存的SQL語句，是否徹底一致，區分大小寫

優缺點：

1 不須要對SQL語句作任何解析和執行，語法解析經過以後，直接從query cache中

得到查詢結構，提升查詢性能

2 查詢緩存的判斷規則，不夠智能，也即提升了查詢緩存的使用門坎，下降了效率

3 查詢緩存的使用，會增長檢查和清理query cache中記錄集的開銷

哪些查詢可能不會被緩存：

1 查詢語句中加了SQL_NO_CACHE 參數

2 查詢語句中含有得到值的函數，包含自定義函數，如：now(),curdate(),

get_lock(),rand(),convert_tz(),等

3 對系統數據庫的查詢：mysql、information_schema 查詢語句中使用了SESSION級別變量

或存儲過程當中的局部變量

4 查詢語句中使用了LOCK IN SHARE MODE,FOR UPDATE的語句，查詢語句中使用相似

SELECT..INTO..導出數據的語句

5 對臨時表的查詢操做，存在警告信息的查詢語句，不涉及任何表或視圖的查詢語句；

某用戶只有列級別權限的查詢語句

6 事務隔離級別爲serializable時，全部查詢語句都不能緩存

查詢緩存相關的服務器變量：

查看有關query變量:

SHOW VARIABLES LIKE '%query%';

query_cache_min_res_unit:

查詢緩存中內存塊的最小分配單位，默認4k

較小值會減小浪費，但會致使更頻繁的內存分配操做

較大值會帶來浪費，會致使碎片過多，內存不足

query_cache_limit:

單個查詢結果能緩存的最大值，默認爲1M

對於查詢結構過大而沒法緩存的語句，建議使用SQL_NO_CACHE

query_cache_size:

查詢緩存總共可用的內存空間；單位字節，必須是1024的整數倍

最小值爲40K，低於此值有警報

不過mariadb10.2.15貌似沒有警報

query_cache_wlock_invalidate:

若是某表被其餘的會話鎖定，是否仍然能夠從查詢緩存中返回結果

默認值爲OFF，表示能夠在表被其餘會話鎖定的場景中繼續從緩存中返回數據

ON，則表示不容許

query_cache_type:

是否開啓緩存功能，取值爲ON，OFF,DEMAND

0,OFF時，查詢緩存功能關閉

1,ON時，默認值。查詢緩存功能打開，SELECT的結果符合緩存條件即會緩存

不然不緩存

顯示指定SQL_NO_CACHE時，不緩存

2,DEMAND 只有SQL_CACHE的SELECT語句纔會緩存，其餘均不緩存

查詢緩存相關的狀態變量：

查看方式：

SHOW GLOBAL STATUS LIKE 'Qcache%';

Qcache_free_blocks 1

處於空閒狀態query cahe中內存block數

Qcache_free_memory 20460888

處於空閒狀態的query cache 內存總量

Qcache_hits 17

命中次數

Qcache_inserts 5

向query cache中插入新的query cashe的次數，即沒有命中次數

Qcache_lowmem_prunes 0

當前query cache內存容量不夠，須要刪除舊的query cache 的次數

Qcache_not_cached 13

沒有被cache的SQL數，包括沒法被cache的以及因爲query_cache_type設置的

不會被cache的SQL語句

Qcache_queries_in_cache 1

在query cache中的SQL數量

Qcache_total_blocks 4

query cache中的總block

命中率和內存使用率估算：

1 查詢緩存中內存塊的最小分配單位query_cache_min_res_unit ：

(query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

 2 查詢緩存命中率：Qcache_hits / ( Qcache_hits + Qcache_inserts ) * 100%

 3 查詢緩存內存使用率：(query_cache_size – qcache_free_memory) /

query_cache_size * 100%

innodb存儲引擎的緩衝池：

一般innodb存儲引擎緩衝池的命中不該該小於99%

查看innodb相關狀態變量：

SHOW GLOBAL STATUS LIKE 'innodb%read%';

 Innodb_buffer_pool_reads: 表示從物理磁盤讀取頁的次數

 Innodb_buffer_pool_read_ahead: 預讀的次數

 Innodb_buffer_pool_read_ahead_evicted: 預讀頁，可是沒有讀取就從緩

衝池中被替換的頁數量，通常用來判斷預讀的效率

 Innodb_buffer_pool_read_requests: 從緩衝池中讀取頁次數

 Innodb_data_read: 總共讀入的字節數

 Innodb_data_reads: 發起讀取請求的次數，每次讀取可能須要讀取多個頁

優化查詢緩存：

1 緩存命中率是否能夠接受

2 如緩存命中率能夠接受結束，如不能，檢查大部分查詢是否都不是可緩存的

3 如都是不可緩存，檢查query_cache_limit是否足夠大，若是是，結束，查詢本是

不能被緩存。若是否，增長query_cache_limit

4 若是都是可緩存的。檢查是否發生了不少驗證工做

若是否，檢查緩存是否被啓動，沒有啓動則啓動，已啓動則結束

若是是，執行5

5 檢查緩存是否被碎片化，

若是是，則減小query_cache_res_unit，或者使用FLUSH QUERY CACHE命令減小碎片

若是否，執行6

6 是否有不少由於內存太低而發生的修整工做，即緩存是否頻繁被丟棄

若是是，增長query_cache_size。

若是否，執行7

7 是否有不少更新語句。若是是，結束，負載不適合緩存。

若是否，有其餘的東西被配置錯了，從新檢查配置

索引：-------------------------------------------------------------------------

索引是特殊數據結構：定義在查找時做爲查找條件的字段

索引實如今存儲引擎

優勢：

索引能夠下降服務須要掃描的數據量，減小io次數

索引能夠幫助服務器避免排序和使用臨時表

索引能夠幫助將隨機I/O轉爲順序I/O

缺點：

佔用額外空間，影響插入速度

索引類型：

B+TREE、HASH、 R TREE

聚簇索引，非聚簇索引：

索引中數據的順序是否和原表數據一致

主鍵索引、二級（輔助）索引

稠密索引、稀疏索引：

是否索引了每個數據項

簡單索引、組合索引

左前綴索引：取前面的字符作索引

覆蓋索引：從索引中便可取出要查詢的數據，性能高

B+ tree索引：

順序存儲，每個葉子節點到根節點的距離是相同的

左前綴索引，適合查詢範圍類數據

可使用B+tree索引的查詢類型：

全值匹配：精確全部索引列

匹配最左前綴：即只使用索引的第一列

匹配列前綴：只匹配一列值開頭部分，

匹配範圍值：

精確匹配某一列並範圍匹配另外一列：

只訪問索引的查詢：

限制：

若是不能從最左列開始，則沒法使用索引

不能跳過索引中的列、

若是查詢中某個列是爲範圍查詢，那麼其右側的列都沒法再使用索引

特別提示：

索引列的順序和查詢語句的寫法應相匹配，才能更好的利用索引

爲優化性能，可能須要針對相同的列但順序不一樣建立不一樣的索引來知足不一樣

類型的查詢需求

Hash索引：

基於哈希表實現，只有精確匹配索引中的全部列的查詢纔有效，索引自身只存儲索引列

對應的哈希值和數據指針，索引結構緊湊，查詢性能好

只有Memory存儲引擎支持顯示hash索引

適用場景：

只支持等值比較的查詢，包括=，<=>,IN()

不適用使用hash索引的場景：

不適用於順序查詢：索引的存儲順序不是值的順序

不支持模糊查詢

不支持範圍查詢

不支持部分索引列匹配查找，

空間索引：

R-tree：MyISAM支持空間索引，但是使用任意維度組合查詢，使用特有的函數訪問

經常使用於作地理數據存儲，使用很少

全文索引：FULLTEXT

在文本中查找關鍵詞，而不是直接比較索引中的值，相似搜索引擎

聚簇和非聚簇索引：

聚簇索引：

生成一份原表數據副本，而且將生成的數據副本按照所選列重新排序

因爲數據和索引在一塊兒，查找時找到索引項，便可直接找到數據

非聚簇索引：

索引和數據不放在一塊兒，且存放的順序不一致

查找時找到索引項，以後經過索引項中指針記錄的地址找到數據

冗餘和重複索引：

冗餘索引：(A),(A,B)

此爲很差的索引使用策略，建議擴展索引，而非冗餘

（B），（A,B）

此爲非冗餘

重複索引：已經有索引，再次創建索引

索引優化策略：

1 獨立的使用列：

儘可能避免其參與運算，獨立的列指索引列不能是表達式的一部分，也不能是函數的

參數，在WHERE語句中，始終將索引列單獨放在比較符號的一側

2 左前綴索引：

構建指定索引字段的左側的字符數，用經過索引選擇性來評估

索引選擇性：不重複的索引值和數據表的記錄總數的比值

3 多了索引：

AND操做時更適合使用多列索引，而非每一個列建立單獨的索引

4 選擇合適的索引列順序：無排序和分組時，將選擇性最高放左側

索引優化建議：

1 只要列中含有NULL值，就最好不要再此列設置索引

符合索引若是有NULL值，此列在使用時也不會使用索引

2 儘可能使用短索引，若是能夠，應該制定一個前綴長度

3 對於常常在where子句使用的列，最好設置索引

4 對於有多個列where或者order by子句，應該創建複合索引

5 對於like語句，以'%'或者'_'開頭的不會使用索引，以‘%’結尾會使用索引

6 儘可能不要再列上進行運算（函數操做和表達式操做）

7 儘可能不要使用 not in 和<>操做

8 查詢時，能不要*就不用*，儘可能寫全字段名

9 大部分狀況鏈接效率遠大於子查詢

10 多表鏈接時，儘可能小表驅動大表，即小表join 大表

11 在千萬級分頁時使用limit

12 對於常用的查詢，能夠開啓緩存

13 多使用explain和profile分析查詢語句

14 查看慢查詢日誌，找出執行時間長的sql語句優化

管理索引：

建立索引：HELP CREATE INDEX

CREATE INDEX index_name ON tb_name(index_col,..);

刪除索引：

DROP INDEX index_name ON tb_name;

查看索引：

SHOW INDEX FROM tb_name;

優化表空間：

OPTIMIZE TABLE tb_name;

查看索引的使用：

SET GLOBAL userstat=1；

SHOW INDEX_STATISTICS;

EXPLAIN:

經過EXPLAIN來分析索引的有效性：

EXPLAIN SELECT clause；

獲取查詢執行計劃信息，用來查看查詢優化器如何執行查詢

輸出信息說明：

官方文檔地址：https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

示例：

MariaDB [hellodb]> EXPLAIN SELECT * FROM students WHERE stuid=15\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: students

type: const

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: const

rows: 1

Extra:

1 row in set (0.00 sec)

id：當前查詢語句中，每一個SELECT語句的編號

複雜類型的查詢有三種：

簡單子查詢

用於FROM中的子查詢

聯合查詢：UNION

注意：UNION 查詢的分析結構會出現一個額外匿名臨時表

select_type:

簡單查詢爲:SIMPLE

複雜查詢：

SUBQUERY:簡單子查詢

PRIMARY:最外面的SELECT

DERIVED:用戶FROM中的子查詢

UNION:UNION語句的第一個以後的SELECT語句

UNION RESULT：匿名臨時表

table：SELECT 語句關聯到的表

type：關聯類型或訪問類型，即Mysql決定的如何去查詢表中的行的方式

如下順序，性能由低到高

ALL：全表掃描

index：根據索引的次序進行全表掃描；

若是在Extra出現"Using index"表示使用了覆蓋索引，而非全表掃描

range：有範圍限制的根據索引實現的範圍掃描，掃描位置始於索引中的某一個點

結束於另外一點

ref：根據索引返回表中匹配某單個值的全部行

eq_ref: 僅返回一個行，但須要與額外的某個參考值作比較

const，system：直接返回單個行

possible_keys: 查詢可能會用到的索引

key：查詢中使用到的索引

key_len: 在索引使用的字節數

ref：在利用key字段所表示的索引完成查詢時所用的列或某某常量值

rows： mysql估計爲找全部的目標行而須要讀取的行數

extra：額外信息

using index： mysql將會使用覆蓋索引，以免訪問表

using where： mysql服務器將在存儲引擎檢索後，在進行一次過濾

using temporary：MYSQL對結果排序時會使用臨時表

using filesort：對結果使用一個外部索引排序

併發控制、事務：------------------------------------------------------------------------

併發控制：

鎖粒度：表級鎖，行級鎖

鎖：

讀鎖：共享鎖，只讀不可寫，多個讀互不阻塞

寫鎖：獨佔鎖，排它鎖，一個寫鎖會阻塞其餘讀和寫鎖

實現：

存儲引擎：自行實現其鎖策略和鎖粒度

服務器級：實現了鎖，表級鎖；用戶可顯示請求

分類：

隱式鎖：由存儲引擎自動施加鎖

顯式鎖：用戶手動請求

鎖策略：

在鎖粒度及數據安全性尋求的平衡機制

顯示使用鎖：

鎖定：

LOCK TABLES tb_name[[AS] alias] lock_type

[,tb_name [[AS] alias] lock_type]...

lock_type READ,WRITE

解鎖：

UNLOCK TABLES;

全局讀鎖：

一般在備份前加全局讀鎖，關閉正在打開的表（清除查詢緩存）

FLUSH TABLES [tb_name[,...]] [WITH READ LOCK]

查詢時加寫鎖或讀鎖：

SELECT clause [FOR UPDATE|LOCK IN SHARE MODE]

事務：------------------

事務TRANSACTIONS:一組原子性的SQL語句，或一個獨立工做單元

事務日誌：記錄事務信息，實現undo，redo等故障恢復功能

ACID特性:

A: atomicity,原子性，整個事務中的全部操做要麼所有成功執行，要麼

所有失敗後回滾

B： consisitency，一致性，數據庫老是從一個一致性狀態轉換爲另外一個一致性狀態

I： isolation，隔離性，一個事務所作出的操做在提交以前，是不能爲其餘事務所見

隔離有多種隔離級別，實現併發

D： durability，持久性，一旦事務提交，其所作的修改會永久保存於數據庫中

啓動事務：

START TRANSACTION

結束事務：

1 COMMIT 提交

2 ROLLBACK 回滾

事務的生存週期：

initial db state ---> START TRANSACTION ---> INSERT,UPDATE

---> COMMIT ---> new db state

---> ROLLBACK ---> initial db state

注意：只有事務型存儲引擎的DML語句方能支持此類操做

即 INSERT,UPDATE,DELETE

其餘語句如CREATE,DROP,ALTER 均不支持回滾

建議：顯示請求和提交事務，而不要使用"自動提交" 功能

SET autocommit={1|0};

事務支持保存點：SAVEPOINT

SAVEPOINT P1;

DELETE|UPDATE|INSERT...

SAVEPOINT P2;

DELETE...

ROLLBACK [WORK] [TO [SAVEPOINT] p1|p2] ;

事務的隔離級別：

從上至下更加嚴格：

READ UNCOMMITTED: 可讀取到未提交數據，產生髒讀

READ COMMITED: 可讀取到提交數據，但未提交數據不可讀，產生不可重複讀

便可讀取到多個提交數據，致使每次讀取數據不一致

REPEATABLE READ: 事務開始以後產生的數據改變將沒法讀取，始終保持事務開始

以前的數據狀態。可重複讀，屢次讀取數據一致

會產生幻讀，即便有其餘提交的事務修改數據，扔能讀取到未修改

前的舊數據。

此爲mysql默認設置。

SERIALIZABLE: 可串行化，未提交的讀事務阻塞修改事務，或者未提交的修改事務

阻塞讀事務。致使併發性能差。

MVCC：多版本併發控制，和事務級別相關

指定事務隔離級別：

服務器變量tx_isolation指定

默認爲REPEATABLE-READ,可在GLOBAL和SESSION 級別進行設置

SET [GLOBAL] tx_isolation=

READ-UNCOMMITTED

READ-COMMITTED

REPEATABLE-READ

SERIALIZABLE

服務器選項中指定:

vim /etc/my.cnf

[mysqld]

transaction-isolation=SERIALIZABLE|..

死鎖：

兩個或多個事務在同一資源相互佔用，並請求鎖定對方佔用的資源的狀態

mysql日誌：---------------------------------------------------------------------

日誌類型：

事務日誌： transaction log

中繼日誌： reley log

錯誤日誌： error log

通用日誌： general log

慢查詢日誌：slow query log

二進制日誌：binary log

事務日誌：

事務型存儲引擎自行管理和使用，用於系統崩潰以後的數據恢復。

建議和數據文件分開存放

redo log

undo log

事務日誌的寫入類型爲"追加"，所以其操做爲「順序IO」;一般也被稱爲：

預寫入日誌：write ahead logging

ib_logfile0,ib_logfile1

innodb事務日誌相關配置：

SHOW VARIABLES LIKE '%innodb_log%';

innodb_log_file_size 50331648 大小，默認5M

innodb_log_files_in_group 2 數量，默認2個

innodb_log_group_home_dir ./ 默認數目錄下

中繼日誌：

relay log

主從複製架構中，從服務器用於保存從主服務器的二進制日誌中讀取的事件

錯誤日誌：

記錄內容：

mysqld 啓動和關閉過程當中輸出的事件信息

mysqld 運行中產生的錯誤信息

event scheduler運行一個event時產生的日誌信息

在主從複製架構中的從服務器上啓動從服務器線程時產生的信息

錯誤日誌相關配置：

SHOW GLOBAL VARIABLES LIKE 'log_error';

錯誤文件路徑：

[mysqld_safe]

log-error=/var/log/mariadb/mariadb.log

是否記錄警告信息至錯誤日誌文件：

log_warnings=1|0|2 10.2.15默認值2

通用日誌：

general_log: 記錄對數據庫的通用操做，包括錯誤的SQL語句

默認爲關閉，如無特殊需求，不要開啓

記錄位置：

文件：file，默認值

表： table

通用日誌相關設置：

general_log=ON|OFF

general_log_file=HOSTNAME.log

log_output='TABLE'|'FILE'|NONE

慢查詢日誌：

記錄執行查詢時長超出指定時長的操做

SHOW VARIABLES LIKE '%slow%' | '%query';

slow_query_log=ON|OFF 開啓或關閉慢查詢

long_query_time=N 慢查詢的閥值

slow_query_log_file=HOSTNAME-slow.log 慢查詢日誌文件

log_slow_filter = admin,filesort,filesort_on_disk,full_join,

full_scan,query_cache,query_cache_miss,tmp_table_on_disk

上述查詢類型且查詢時長超過long_query_time，則記錄日誌

log_queries_not_using_indexes=ON

不使用索引或者全索引掃描，不管是否達到慢查詢閥值的語句是否記錄日誌

默認OFF，即不記錄

log_slow_rate_limit=1 多少次查詢才記錄，mariadb特有

log_slow_verbosity= query_plan,explain 記錄內容

log_slow_queries = OFF 同爲slow_query_log 新版已廢棄

二進制日誌：binary log

功能：

記錄致使數據改變或潛在致使數據改變的SQL語句

記錄已提交的日誌

不依賴於存儲引擎類型

功能: 經過「重放」日誌文件中的事件來生成數據副本

特別注意：二進制文件和數據文件應該分開存放

記錄格式：

SHOW VARIABLES LIKE 'binlog_format';

1 基於"語句"記錄：statement，記錄語句

2 基於"行"記錄，row，記錄數據，日誌量較大

3 混合模式：mixed，讓系統自行斷定該基於哪一種方式進行

格式配置：

SHOW VARIABLES LIKE 'binlog_format';

二進制日誌文件的構成：

日誌文件：文件名.000001,二進制格式

索引文件：文件名.index，文本格式

二進制日誌相關服務器變量：

sql_log_bin=ON|OFF 是否記錄二進制日誌，默認ON

log_bin=/path/file 指定文件位置，可使用相對路徑，默認OFF，指定則開啓二進制日誌

binlog_format=STATAMENT|ROW|MIXED:

二進制日誌記錄的格式，mariadb10.2.15默認mixed

max_binlog_size= 單個二進制日誌文件的最大致積，到達最大值會自動滾動，默認1G

sync_binlog=1|0 設置是否啓動二進制日誌即時同步磁盤功能，默認0，由操做系統負責同步日誌到磁盤

expire_logs_days=N 二進制日誌能夠自動刪除的天數。默認爲0，即不自動刪除

二進制日誌相關配置：

SHOW MASTER|BINARY LOGS;

查看mariadb自行管理使用中的二進制日誌文件列表，及大小

SHOW MASTER STATUS;

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

SHOW BINLOG EVENT [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

查看二進制文件中的指定內容：

例如：

SHOW BINLOG EVENTS IN 'mysql-bin.000032' FROM 574 LIMIT 1,2;

mysqlbinlog:

二進制日誌的客戶端命令工具

命令格式：

mysqlbinlog [options] log_file... [ > file.sql]

--start-position= 指定開始位置

--stop-position=

--start-datetime=

--stop-datetime=

時間格式YYYY-MM-DD hh:mm:ss

--base64-output[=name]

示例：

mysqlbinlog --start-position=256 --stop-position=2534 mysql-bin.000010

mysqlbinlog --start-datetime="2018-06-07 15:31:30"

--stop-datetime="2018-06-07 16:23:17" mysql-bin.000010

二進制日誌事件的格式：

#180614 15:21:43 server id 1 end_log_pos 3976 CRC32 0xa52dcef8 GTID 0-1-304

/*!100001 SET @@session.gtid_seq_no=304*//*!*/;

BEGIN

/*!*/;

# at 3976

#180614 15:21:43 server id 1 end_log_pos 4088 CRC32 0x6149d2a9 Query thread_id=36 exec_time=0 error_code=0

SET TIMESTAMP=1528960903/*!*/;

UPDATE mysql.user SET password=PASSWORD('centos')

/*!*/;

事件發生的日期和時間：180614 15:21:43

事件發生的服務器標識：server id 1

事件的結束位置：end_log_pos 3976

事件的類型：Query

事件發生時所在服務器執行此事件的線程的ID：thread_id=36

語句的時間戳與將其寫入二進制文件中的時間差：exec_time=0

錯誤代碼：error_code=0

事件內容：

GTID：Global Transaction ID，mysql5.6以mariadb10以上版本專屬屬性：GTID

清除指定二進制日誌：

PURGE {BINARY|MASTER} LOGS {TO 'log_name'|BEFORE datetime_expr};

示例:

PURGE MASTER LOGS TO mysql-bin.000031;

PURGE MASTER LOGS BEFORE '2018-06-20 12:00:00';

PURGE MASTER LOGS BEFORE '2018-06-21';

刪除全部二進制日誌：

RESET MASTER [TO #]

日誌文件從#開始從新計數，默認1, index文件從新記數

切換二進制日誌文件：

FLUSH LOGS;

mysql 備份和恢復：----------------------------------------------------------------

爲何要備份：

災難恢復

硬件故障，軟件故障，天然災害，××××××，誤操做測試等數據丟失場景

備份注意要點：

能容忍最多丟失多少數據

恢復數據須要在多長時間內完成

須要恢復哪些數據

還原要點：

作還原測試，用於測試備份的可用性

還原演練，確保緊急時刻可以熟練可靠的還原數據

備份類型：

徹底備份，部分備份

徹底備份：備份整個數據集

部分備份：只備份數據子集，如部分數據庫

徹底備份，增量備份，差別備份

增量備份：僅備份最近一次徹底備份或增量備份（若是存在增量）以來變化的數據

備份較快，還原複雜

差別備份：僅備份最近一次徹底備份以來變化的數據

備份較慢，消耗更多磁盤空間，還原簡單

冷備，溫備，熱備：

冷備：讀寫操做均不可進行

溫備：讀操做可執行，寫操做不可執行

熱備：讀寫操做都可執行

MyISAM 只支持溫備

InnoDB：都支持

物理備份和邏輯備份：

物理備份：直接複製數據文件進行備份，與存儲引擎有關，佔用較多的空間，速度快

邏輯備份：從數據庫中"導出"數據另存而進行的備份，與存儲引擎無關，佔用空間少，速度慢，可能丟失精度

備份時須要考慮的因素：

溫備的持鎖多久

備份產生的負載

備份過程的時長

恢復過程的時長

備份什麼：

數據

二進制日誌、innodb的事務日誌

程序代碼（存儲過程、函數、觸發器、事件調度器）

服務器的配置文件

備份工具：

1 cp，tar等複製歸檔工具：物理備份工具，適用全部存儲引擎，只支持冷備；

徹底和部分備份

2 LVM的快照：先加鎖，作快照後解鎖，幾乎熱備；藉助文件系統工具進行備份

3 mysqldump：邏輯備份工具，適用全部存儲引擎，溫備；支持徹底或部分備份；

對InnoDB存儲引擎支持熱備，結合binlog的增量北風

4 xtrabackup：由percona提供支持，對InnoDB作熱備（物理備份）的工具，支持

徹底備份，增量備份

5 MariaDB Bachup：從MariaDB 10.1.26開始集成，基於percona xtrabackup2.3.8

6 mysqlbackup：熱備份，mysql enterprise edition組件

7 mysqlhotcopy：幾乎冷備，僅適用於MyISAM存儲引擎

-------------------------------------------------------------------------------

基於LVM實現備份和恢復：

1 準備初始環境

MYSQL數據目錄 /data/mydata 掛載邏輯卷 /dev/vg0/data_mysql

MYSQL二進制文件目錄 /data/mylog 掛載邏輯卷 /dev/vg0/binlog_mysql

mysql -uroot -pcentos <hellodb_innodb.sql 導入數據庫hellodb

CREATE DATABASE db1; 新建數據庫db1

GRANT ALL ON db1.* TO 'user1'@'192.168.65.%' IDENTIFIED BY 'centos';

新建一個用戶user1，受權user1 對db1全部權限

2 實現徹底備份

請求鎖定全部表

FLUSH TABLES WITH READ LOCK;

記錄二進制日誌文件及事件位置

FLUSH LOGS;

SHOW MASTER STATUS;

mysql -uroot -pcentos -e 'SHOW MASTER STATUS' > /data/backup/binlog_point-0

建立快照：

lvcreate -L 5G -s -p r -n snap_mysql /dev/vg0/data_mysql

釋放鎖：

UNLOCK TABLES;

掛載快照卷，注意，uuid衝突，沒法直接掛載

mount -o ro,nouuid,norecovery /dev/vg0/snap_mysql /mnt

複製數據：

mkdir -pv /data/backup/fullbackup1

cp -a /mnt/* /data/backup/fullbackup1/

刪除快照卷：

umount /dev/vg0/snap_mysql

lvremove /dev/vg0/snap_mysql

3 實現增量備份

模擬使用過程：

use db1；

CREATE TABLE stu1 SELECT name,age FROM hellodb.students;

use hellodb；

DROP TABLE students;

記錄二進制日誌文件及事件位置：

FLUSH LOGS;

SHOW MASTER STATUS;

mysql -uroot -pcentos -e 'SHOW MASTER STATUS' > /data/backup/binlog_point-1

導出二進制文件：

cat /data/backup/binlog_point-0

mysqlbinlog --start-position=385 /data/mylog/mysql-bin.000002

> /data/backup/binlog1.sql

若是已記錄多個文件，從上一次備份以後到這一次刷新以前的全部日誌均須要導出

後續使用 ">>" 追加便可

4 還原測試：

假設後續使用了一段時間

DROP TABLE classes;

CREATE TABLE te1 SELECT * FROM teachers;

而後系統奔潰，數據所有丟失，

這裏使用rm -rf /data/mydata/* 模擬

關閉mysqld：

複製徹底備份文件：

cp -a /data/backup/fullbackup1/* /data/mydata/

開啓mysqld，可是不能對外提供服務，關閉網絡服務，或者前端調度器配合

因爲須要作二進制日誌還原，可是在重放過程當中會生成新的打量二進制日誌

因此還須要暫時關閉二進制日誌功能

vim /etc/my.cnf

[mysqld]

skip_networking

註釋掉 log-bin=/data/mylog/mysql-bin

systemctl start mysqld

使用 mysql -uroot -p 連入數據庫

（可選步驟，測試徹底備份是否恢復）

use db1;

SHOW TABLES; 能夠發現db1存在，TABLE db1.stu1 不存在

SHOW GRANTS FOR 'user1'@'192.168.65.%'; 用戶user1權限已恢復

use hellodb;SHOW TABLES; students 還在

恢復增量備份：

msyql -uroot -pcentos < /data/backup/binlog1.sql

可能須要恢復屢次

（測試是否恢復）

use db1;SHOW TABLES;SELECT * FROM stu1; 已恢復

use hellodb;SHOW TABLES; students表已不存在

可是classes還在，仍然不是最新狀態

恢復最近數據：

因爲二進制文件和數據分開存儲，因此假設最近的二進制文件未損壞

查看應該還原的二進制日誌開始位置

cat /data/binlog_point-1

mysql-bin.000003 385

導出二進制日誌：

mysqlbinlog --start-position=385 mylog/mysql-bin.000003 >logfile.sql

經過二進制日誌文件，恢復最近數據

mysql -uroot -pcentos <logfile.sql

測試查看：

use hellodb；SHOW TABLES;

發現classes表已刪除，數據庫恢復最近狀態

5 重啓，恢復服務

vim /etc/my.cnf

刪除 skip_networking

取消註釋：log-bin=/data/mylog/mysql-bin

重啓服務: systemctl restart mysqld

-------------------------------------------------------------------------------

mysqldump 使用：

mysqldump工具：客戶端命令，經過mysql協議鏈接至mysql服務器進行備份

使用格式：

mysqldump [options] database [tables]

不會備份create table

mysqldump [options] -B db1 [db2 db3..]

mysqldump [options] -A [options]

常見選項：

-A,--all-databases 備份全部數據庫，含create databases

-B，--databases db_name... 指定備份的數據庫，包含create databases語句

-E，--event: 備份相關的全部event scheduler

-R, --routines：備份全部存儲過程和自定義函數

--triggers：備份表相關觸發器，默認啓用,用--skip-triggers，不備份觸發器

--master-data[=#] 此選項需啓用二進制日誌

會在備份出的數據以前加一條記錄 CHANGE MASTER TO 語句

=1 不註釋

=2 顯示，但註釋

此選項會自動關閉--lock-tables功能，自動打開-x|--lock-all-tables功能

除非開啓--single-transaction

-F，--flush-logs:備份前滾動日誌，鎖定完成後，執行flush logs命令，生成

新的二進制日誌文件，配合-A或-B選項時，會致使刷新屢次數據庫

建議在同一時刻執行轉儲和日誌刷新，可經過和--single-transaction

或-x，--master-data一塊兒使用實現，此時只刷新一第二天志

--compact 去掉註釋，適合調試，生成不使用

-d，--no-data 只備份表結構

-t，--no-create-info 只備份數據，不備份create table

-n，--no-create-db 不備份create database，可被-A或-B覆蓋

--flush-privileges 備份mysql或相關時須要使用

-f, --force 忽略SQL錯誤，繼續執行

--hex-blob 使用十六進制符號轉儲二進制列（例如，「abc」變爲0x616263），

受影響的數據類型包括BINARY， VARBINARY，BLOB，BIT

 -q, --quick 不緩存查詢，直接輸出，加快備份速度

MyISAM備份選項：

支持溫備；不支持熱備，因此必須先鎖定要備份的庫，然後啓動備份操做

鎖定方法以下：

-x,--lock -all-tables：加全局讀鎖，鎖定全部庫的全部表，同時加--singletransaction或--lock -tables選項會關閉此選項功能

注意：數據量大時，可能會致使長時間沒法併發訪問數據庫

-l,--lock -tables：對於須要備份的每一個數據庫，在啓動備份以前分別鎖定其所

有表，默認爲on,--skip-lock -tables選項可禁用,對備份MyISAM的多個庫,可能

會形成數據不一致

注：以上選項對InnoDB表同樣生效，實現溫備，但不推薦使用

InnoDB備份選項：

支持熱備，可用溫備但不建議用

--single-transaction

此選項Innodb中推薦使用，不適用MyISAM

此選項會開始備份前，先執行START TRANSACTION 指令開啓事務

此選項經過在單個事務中轉儲全部表來建立一致的快照。

僅適用於存儲在支持多版本控制的存儲引擎中的表（目前只有innodb）

轉儲不保證與其它存儲引擎保持一致

在進行單事務轉儲時，要確保有效的轉儲文件（正確的表內容和二進制日誌位置）

沒有其餘鏈接應該使用如下語句：ALTER TABLE,DROP TABLE,RENAME TABLE,TRUNCATE TABLE

此選項和--lock-tables(此選項隱含提交掛起的事務)選項是相互排斥的

備份大型表時，建議將--single-transaction 選項和 --quick選項結合一塊兒使用

缺點：

速度慢，不適合備份大型數據庫

----------------------------------------------------------------------------------

使用mysqldump實現備份與恢復：

1 徹底備份

mysqldump -A -F --single-transaction --quick --master-data=2

> /data/backup/full.sql

2 修改數據，並獲取二進制日誌起始位置

數據修改

獲取二進制日誌起始位置

FLUSH LOGS;

SHOW MASTER LOGS;SHOW MASTER STATUS;

獲取FLUSH以前的日誌文件爲結束位置

less /data/backup/full.sql

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=385;

經過查看全備份文件，獲取起始位置

3 導出二進制日誌

mysqlbinlog --start-position=385 /data/mylog/mysql-bin.000004

>/data/backup/log.sql

mysqlbinlog /data/mylog/mysql-bin.000005 >> /data/backup/log.sql

注意除第一個外，後續的日誌文件導出均須要使用追加 >>

4 本機恢復過程

關閉服務：

刪除數據目錄下全部文件： rm -rf /data/mydata/*

vim /etc/my.cnf

添加skip-networking

註釋掉log-bin=/data/mylog/mysql-bin

開啓服務：

導入數據：

mysql < /data/backup/full.sql

導入二進制日誌數據：

mysql < /data/backup/log.sql

修改配置文件，vim /etc/my.cnf

註釋skip-networking

取消註釋log-bin=/data/mylog/mysql-bin

重啓服務

5 備用機恢復過程，假設原服務器崩潰沒法啓動，且備份數據單獨保存，

在備用機上裝好mariadb，將備份數據傳到新服務器

開啓服務並導入數據：

mysql < /data/backup/full.sql

mysql </data/backup/log.sql

將新服務器接入調度器，開始提供服務

注意：經過yum安裝的mariadb5.5.56 在刪除數據目錄rm -rf /data/mydata/*

以後，重啓服務會自動生成mysql數據庫

而經過二進制安裝的10.2.15則不會自動生成，須要手動生成，使用

./scripts/mysql_install_db --data= ...

誤操做刪除，如何恢復數據：

主要操做過程跟上面同樣

只是在最後利用二進制日誌恢復數據時，須要使用

grep DROP TABLES.... /data/backup/log.sql 定位誤操做哪一行

而後使用 sed '/.../d' /data/backup/log.sql 刪除錯誤操做

以後按正常流程恢復數據便可

注意：仍然可能會存在問題，由於後續的操做可能基於此項修改作了變更，致使數據不一致

因此操做需謹慎

使用mysqldump實現單表備份和恢復：

以hellodb.students 表爲例

1 備份

mysqldump --single-transaction --quick hellodb.students

> /data/stu.sql

mysql -e 'SHOW CREATE TABLE hellodb.students' >/data/stu.create.sql

2 修改create.sql

vim /data/stu.create.sql

將其中重複的create 語句刪除

3 恢復數據

mysql> source /data/stu.create.sql

mysql> source /data/stu.sql

3 恢復數據，也可使用vim分別打開/data/stu.create.sql 和/data/stu.sql

分別在create 和insert 語句以前加上

use hellodb；

而後在shell命令行恢復數據

mysql > /data/stu.sql

mysql > /data/stu.create.sql

---------------------------------------------------------------------------------

xtrabackup介紹：

percona官網：www.percona.com

xtrabackup:

percona提供的mysql數據庫備份工具，惟一開源的可以對innodb和xtradb數據庫進行

熱備的工具

手冊：https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

特色：

備份還原過程快速、可靠

備份過程不會打斷正在執行的事務

可以基於壓縮等功能節約磁盤空間和流量

自動實現備份檢驗

開源，免費

xtrabackup2.2版以前包括4個可執行文件：

innobackupex: perl腳本

xtrabackup： c，c++編譯的二進制

xbcrypt：加解密

xbsteam：支持併發寫的流文件格式

xtrabackup：是用來備份innodb表的

不能備份非innodb表，和mysql server沒有交互

innoback：用來備份非innodb表，同時會調用xtrabackup命令來備份innodb表

還會和mysql server發送命令進行交互，如加全局讀鎖（FTWRL）、

獲取位點（SHOW SLAVE STATUS）等.

即innobackupex 是在xtrabackup之上作了一層封裝實現的

雖然目前通常不用 MyISAM表，只是mysql庫下系統表時myisam的，所以備份基本

都經過innobackup命令進行

xtrabackup版本變化：

升級到2.4後，相比以前的2.1有了比較大的變化：

innobackup功能所有集成到xtrabackup裏面，只有一個binary程序，另外

爲了兼容考慮，innobackupex做爲xtrabackup的軟連接，即xtrabackup如今

支持費innodb表備份，而且innobackupex 在下一版中移除，建議經過xtrabackup

替換innobackupex

xtrabackup安裝：

yum install percona-xtrabackup epel源

最新版本下載安裝：

https://www.percona.com/downloads/XtraBackup/LATEST/

Xtrabackup用法：

備份：innobackupex [option] BACKUP-ROOT-DIR

選項說明：https://www.percona.com/doc/percona-xtrabackup/LATEST/genindex.html

--user 表示備份帳號

--password 表示備份的密碼

--host 表示備份數據庫的地址

--databases 接受的參數爲數據庫名，如要指定多個數據庫，彼此間須要以

空格隔開，如:"xtra_test dba_test"

同時，指定某數據庫時，也能夠只指定其中的某張表，如:

"mydatabase.mytable"。

對innodb引擎表無效，仍是會備份全部innodb表

--defaults-file 指定從哪一個文件讀取MYSQL配置，必須放在命令行第一個選項位置

--incremental 表示建立一個增量備份

須要指定 --incremental-basedir

--incremental-basedir 指定爲前一次全備份或增量備份的目錄，

與--incremental同時使用

--incremental-dir 該選項表示還原時增量備份的目錄

--include=name 指定表名，格式 databasename.tablename

Prepare:還原準備

innobackup --apply-log [option] BACKUP-DIR

選項說明：

--apply-log: 通常狀況下，在備份完成後，數據尚且不能用於恢復操做，

由於備份的數據中可能會包含還沒有提交的事務或已經提交但還沒有同步至

數據庫中的事務。

所以，此時數據文件仍處於不一致狀態。

此選項做用是經過回滾未提交的事務及同步已經提交事務至數據文件，使

數據文件處於一致性狀態。

--use-memory：該選項表示和--apply-log選項一塊兒使用，prepare備份的時候，

xtrabackup和crash recovery 分配的內存大小，單位字節。

也可（1MB,1M,1GB,1G），推薦1G

--export 表示開啓可導出單獨的表以後再導入其餘mysql中

--redo-only 在prepare base full backup ，往其中merge 增量備份時候使用

還原：innobackupex --copy-back [option] BACKUP-DIR

innobackupex --move-back [option] [--defaults-group=GROUP-NAME] BACKUP-DIR

選項說明：

--copy-back：作數據恢復時將備份數據文件拷貝到mysql服務器的datadir

--move-back：這個選項與--copy-back類似，惟一的區別是它不拷貝文件，而是

移動文件到目的地，這個選項移除backup文件，用時候必須當心。

使用場景：沒有足夠的磁盤空間同時保留數據文件和backup副本

還原注意事項：

1 datadir目錄必須爲空。除非指定

innobackupex --force-non-empty-directories選項，不然--copy-backup選項不會覆蓋

2 在restore以前，必須shutdown MYSQL實例，不能將一個運行中的實例restore 到datadir中

3 因爲文件屬性會被保留，大部分狀況下須要在啓動實例以前將文件的屬主改成

mysql，這些文件將屬於建立備份的用戶

chown -R mysql:mysql /data/mysql

以上須要在用戶調用innobackupex以前完成

--force-non-empty-directories：指定該參數時候，使得innobackupex --copy-backup

或--move-back選項轉移文件到非空目錄，已存在的文件不會被覆蓋。

若是--copy-back和--move-back文件須要從備份目錄拷貝一個在datadir已經存在的

文件，會報錯失敗

備份生成的相關文件：

使用innobackupex備份時，其會調用xtrabackup備份全部的innodb表，複製全部

關於表結構定義的相關文件（.frm）,以及MyISAM,MERGE,CSV和ARCHIVE表的相關文件，

同時還會備份觸發器和數據庫配置信息相關的文件，這些文件會被保存至一個以時間

命名的目錄中，在備份時，innobackupex還會在備份目錄中建立以下文件

1 xtrabackup_info: innobackupex工具執行時的相關信息，包括版本，備份選項，

備份時長，備份LSN，BINLOG的位置

2 xtrabackup_checkpoints: 備份類型（如徹底或增量），備份狀態（如是否已經爲

prepare狀態），和LSN（日誌序列號）範圍信息，每一個innodb頁(一般爲16k大小)都會

包含一個日誌序列號，即LSN。LSN是整個數據庫系統的系統版本號，每一個頁面相關

的LSN可以代表此頁面最近是如何發生改變的。

3 xtrabackup_binlog_info: MYSQL服務器當前正在使用的二進制日誌文件及至備份

這一刻位置二進制日誌事件的位置，可利用實現基於binlog的恢復

4 backup-my.cnf: 備份命令用到的配置選項信息

5 xtrabackup_logfile: 備份生成的日誌文件

--------------------------------------------------------------------------------------------

使用xtrabackup實現備份和恢復：

一次徹底備份和恢復過程：

準備環境；

centos7.5 yum 安裝mariadb-server以及xtrabackup

yum install mariadb-server percona-xtrabackup

注意：版本問題可能致使備份出錯

實現步驟：

1 備份過程：在原主機

innobackupex --user=root --password=centos /backup

注意：會在指定備份目錄/backup下生成名稱爲日期時間的目錄以存放備份數據

/backup 最好爲單獨磁盤掛載點，數據和備份分開存放，

也可使用scp 將備份數據傳到遠程主機

2 還原過程，在目標主機（也能夠是原主機）

prepare（準備）數據

innobackupex --apply-log /backup/2018-06-23_10-44-53/

中止服務並清除數據目錄

systemctl stop mariadb

rm -rf /var/lib/mysql

恢復數據：

innobackupex --copy-back /backup/2018-06-23_10-44-53/

chown -R mysql:mysql /var/lib/mysql/

重啓服務：

systemctl start mairadb

xtrabackup 實現徹底、增量備份及還原

1 備份過程,在原主機：

準備備份目錄：

mkdir /backup/{full,incres/{inc1,inc2}}

徹底備份

innobackupex --user=root --password=centos /backup/full/

第一次增量：

innobackupex --user=root --password=centos --incremental /backup/incres/inc1/

--incremental-basedir=/backup/full/2018-06-23_11-10-59/

第二次增量：

innobackupex --user=root --password=centos --incremental /backup/incres/inc2

--incremental-basedir=/backup/incres/inc1/2018-06-23_11-16-04/

2 轉移備份數據

scp -r /backup/* 192.168.65.155:/backup/

3 恢復數據，在目標主機

確保服務關閉狀態: systemctl stop mariadb

清空數據目錄： rm -rf /var/lib/mysql/*

準備數據：

innobackupex --apply-log --redo-only /backup/full/2018-06-23_11-10-59/

--incremental-dir=/backup/incres/inc1/2018-06-23_11-16-04/

innobackupex --apply-log --redo-only /backup/full/2018-06-23_11-10-59/

--incremental-dir=/backup/incres/inc2/2018-06-23_11-18-59/

恢復數據：

innobackupex --copy-back /backup/full/2018-06-23_11-10-59/

chown -R mysql:mysql /var/lib/mysql/

開啓服務：

systemctl start mariadb

xtrabackup 單表導出和導入：

注意：此功能必須開啓innodb_file_per_table

1 單表備份

innobackupex --user=root --password=centos --include='hello.students' /backup

2 備份表結構

mysql -uroot -pcentos -e 'show create table hellodb.students' >/backup/students.sql

3 複製表文件到需求主機：

scp -r /backup/* 192.168.65.155:/backup/

4 目標主機

prepare：

innobackupex --apply-log --export /backup/2018-06-23_13-28-49/

建立表：

vim /backup/students.sql

刪除重複項，首行添加 use hellodb；

mysql < /backup/students.sql

刪除表空間：

ALTER TABLE students DISCARD TABLESPACE;

複製表空間文件：

cp /backup/2018-06-23_13-28-49/hellodb/students.{cfg,exp,ibd}

/var/lib/mysql/hellodb/

chown -R mysql.mysql /var/lib/mysql/hellodb/

導入表：

ALTER TABLE students IMPORT TABLESPACE;

錯誤提示：Got error -1 from storage engine

mysql複製：-------------------------------------------------------------------------

擴展方式：scale up 縱向擴展 scale out 橫向擴展

MYSQL擴展：

讀寫分離

複製：每一個節點都有相同的數據集

向外擴展

二進制日誌

單向

複製的功用：

數據分佈

負載均衡讀

備份

高可用和故障切換

MYSQL升級測試

主從複製線程：

主節點：dump thread：爲每一個slave的I/O thread啓動一個dump線程，用於向

其發送binary log events

從節點：I/O thread：向Master 請求二進制額日誌事件，並保存於中繼日誌中

SQL trread：從中繼日誌中讀取日誌事件，在本地完成重放

跟複製功能相關的文件：

master.info：用於保存slave鏈接至master時的先關信息，

例如帳號，密碼、服務器地址等

relay-log.info: 保存在當前slave節點上已經複製的當前二進制日誌和本地

repaly log 日誌的對應關係

主從複製特色：

異步複製

主從數據不一致比較常見

複製架構：

Master/Slave,Master/Master,環狀複製

一主多從

從服務器還能夠再有從服務器

一從多主：適用於多個不一樣數據庫

複製須要考慮二進制日誌事件的記錄格式：

STATEMENT

ROW

MIXED

Mysql主從複製配置：

主從配置過程：

官方介紹：https://mariadb.com/kb/en/library/setting-up-replication/

https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.html

主節點配置：

1 啓用二進制日誌

[mysqld]

log_bin

2 爲當前節點設置一個全局惟一的ID號

server_id=#

log-basename=master 可選項，設置datadir中日誌名稱，確保不依賴主機名

3 建立有複製權限的用戶帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'host' IDENTIFIED BY 'replpass';

從節點配置：

1 啓動中繼日誌

[mysqld]

server_id=# 設置全局惟一的ID號

relay_log=relay-log relay log的文件路徑，默認值爲hostname-relay-bin

relay_log_index=relay_log.index 默認值爲hostname-relay-bin.index

2 使用有複製權限的用戶帳號鏈接至主服務器，並啓動複製線程

HELP CHANGE MASTER TO

CHANGE MASTER TO

MASTER_HOST='192.168.65.132',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql_binlog.000001',

MASTER_LOG_POS=245,

MASTER_CONNECT_RETRY=10;

若是主節點已經運行了一段時間，且有大量數據時，如何配置並啓動salve節點

1 經過備份恢復數據至從服務器

2 複製起始位置爲備份時，二進制日誌文件及其position

若是要啓動級聯複製，須要在從服務器啓用如下配置

[mysqld]

log_bin

log_slave_updates

複製架構中應該注意的問題：

1 限制從服務器爲只讀

在從服務器上設置

read_only=ON

注意：此限制對擁有SUPER權限的用戶均無效

2 若是要阻止全部用戶，可使用

FLUSH TABLES WITH READ LOCK;

如何取消並清理從服務器：

RESET SLAVE; 在從服務器清楚master.info relay-log.info,relay log,

開始新的relay log，

注意，須要先STOP SLAVE

RESTE SLAVE ALL:清除全部從服務器上設置的主服務器同步信息：

如： PORT,HOST,USER,和password

如何保證主從複製的事務安全：

官方文檔：https://mariadb.com/kb/en/library/server-system-variables/

1 在master節點啓用參數：

sync_binlog=1 每次修改後當即同步二進制日誌到磁盤，會形成性能降低

若是用到的爲innodb存儲引擎：

innodb_flush_logs_at_trx_commit=1

每次事務提交當即同步日誌寫磁盤

innodb_support_xa=ON 默認值，分佈式事務，10.3.0廢除

sync_master_info=# #次事件後master.info同步到磁盤

2 在slave節點啓用服務器選項

skip_relay_start=ON 不自動啓動slave

3 在salve節點啓用參數

sync_relay_log=# #次寫入後同步relay log 到磁盤

sync_relay_log_info=# #次事務後同步relay_log.info 到磁盤

重新配置msyql主從同步：

1 準備環境

主ip 192.168.65.132 從ip192.168.65.155

2 主服務器：

修改配置文件：

vim /etc/my.cnf

[mysqld]

log_bin=/data/mylog/mysql-binlog

server_id=1

重啓服務：

添加受權帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.65.155'

查看binlog日誌文件名稱和position

SHOW MASTER STATUS;

記下position位置

3 從服務器：

修改配置文件

vim /etc/my.cnf

[mysqld]

server_id=2

relay_log=relay-log

relay_log_index=relay-log.index

read_only=ON

重啓服務

添加鏈接：

CHANGE MASTER TO

MASTER_HOST='192.168.65.132',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql_binlog.000001',

MASTER_LOG_POS=245,

MASTER_CONNECT_RETRY=10;

4 開啓複製

從服務器使用：

START SLAVE; 開啓複製

SHOW SLAVE STATUS; 查看鏈接狀態

主服務器可使用

SHOW SLAVE HOSTS; 查看鏈接的從服務器

主服務器已使用一段時間以後，配置主從複製：

1 使用主服務器的一個徹底備份，先恢復至從服務器

若是使用mysqldump實現備份，經過選項

--master-data=1 會在備份文件中自動生成

CHANGE MASTER TO ..語句，後續只需補全信息便可在完成恢復時

同時添加鏈接

若是使用LVM快照備份，須要記下備份時的binlog position，且在恢復完成以後

自行添加鏈接

2 以mysqldump 爲例：

主服務器：

修改配置文件：

vim /etc/my.cnf

log_bin=/data/mylog/mysql_binlog

server_id=1

添加受權帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.65.155'

IDENTIFIED BY 'centos';

執行備份操做：

mysqldump -A -F --single-transaction --quick --master-data=1

>/backup/full.sql

將備份複製到從服務器主機

scp -r /backup/full.sql 192.165.65.155:/backup/

3 從服務器：

修改配置文件：

vim /etc/my.cnf

relay_log=relay-log

relay_log_index=relay.index

server_id=2

read_only=ON

修改備份文件

vim /backup/full.sql

在CHANGE MASTER TO 行修改添加

CHANGE MASTER TO

MASTER_HOST='192.168.65.132',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_CONNECT_RETRY=10，

文件自帶如下兩項，無須修改

MASTER_LOG_FILE=

MASTER_LOG_POS=

導入數據並添加鏈接：

mysql < /backup/full.sql

開始傳送：

START SLAVE;

mysql實現級聯複製：

1 主ip：192.168.65.132

從1，ip：192.168.65.155 從2，ip：192.168.65.160

要求從2服務器須要向從1服務器複製數據，從1服務器向主服務器複製

2 這裏主和從1 因爲已經完成了主從複製，因此只須要將從2 添加爲從1的從便可

主服務器配置，不變

3 從1服務器，

修改配置文件：

vim /etc/my.cnf

[mysqld]

log_bin

log_slave_updates

同時去掉read_only 這一項

重啓服務：

添加受權帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.1658.65.160'

IDENTIFIED BY 'centos'；

生成備份：（若是都是重新配置，就不須要這一步了，

不過須要SHOW MASTER STATUS查看二進制日誌文件以及position），

mysqldump --single-transaction --quick --master-data=1

>/data/full.sql

複製備份文件到從2主機

scp -r /data/full.sql 192.168.65.160:/data/

4 從2服務器

修改配置文件：

vim /etc/my.cnf

[mysqld]

server_id=3

read_only=ON

relay_log=relay-log

relay_log_index=relay.index

修改備份文件，添加：

CHANGE MASTER TO

MASTER_HOST='192.168.65.155',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_CONNECT_RETRY=10,

MASTER_LOG_FILE='mariadb-bin.000002',

MASTER_LOG_POS=245;

啓動服務：

恢復備份並添加鏈接

mysql < /data/full.sql

開啓複製：

START SLAVE;

實現mysql 主主複製：

主主複製：互爲主從

容易產生的問題：數據不一致，所以慎用

考慮要點：自動增加id

配置一個節點使用奇數id

auto_increment_offset=1 開始點

auto_increment_increment=2 增加幅度

另外一個節點使用偶數id

auto_increment_offset=2

auto_increment_increment=2

配置步驟：

1 各節點使用一個惟一server_id

2 都啓動binary log 和relay log

3 建立擁有複製權限的用戶帳號

4 定義自動增加id字段的數值範圍各爲奇數和偶數

5 均把對方指定爲主節點，並啓動複製線程

在上面的實驗中，已經實現了級聯複製

如今此基礎上，實現主服務器和從1服務器之間的主主複製

實現流程：

1 從1節點

修改配置文件，

vim /etc/my.cnf

auto_increment_offset=1

auto_increment_increment=2

log_bin

重啓服務

受權複製帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.65.132'

IDENTIFIED BY 'centos';

2 主暫時鎖定數據庫

FLUSH TABLES WITH READ LOCK;

從1獲取二進制文件position

SHOW MASTER STATUS;

3 主節點

修改配置文件：

vim /etc/my.cnf

auto_increment_offset=2

auto_increment_increment=2

relay_log=relay-log

relay_log_index=relay.index

添加鏈接：

CHANGE MASTER TO

MASTER_HOST='192.168.65.155',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_CONNECT_RETRY=10,

MASTER_LOG_FILE='mariadb-bin.000001',

MASTER_LOG_POS=245;

重啓服務：

啓動複製：START SLAVE

-------------------------------------------------------------------------------

半同步複製：

默認狀況下，mysql的複製功能是異步的，異步複製能夠提供最佳的性能

主庫把binlog日誌發送給從庫即結束，並不驗證從庫是否接受完畢。這意味

着當服務器或從服務器端發生故障時，有可能從服務器沒有接收到主服務器

發送過來的binlog日誌，這就會形成主服務器和從服務器的數據不一致。

甚至在恢復時形成數據的丟失

半同步複製實現：

1 首先，實現主從複製

2 主服務器配置

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

SHOW VARIABLES LIKE '%semi%';

SET GLOBAL rpl_semi_sync_master_enabled=1;

SHOW GLOBAL STATUS LIKE '%semi%';

3 從服務器配置：

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

SHOW VARIABLES LIKE '%semi%'

SET GLOBAL rpl_semi_sync_slave_enabled=1;

SHOW VARIABLES LIKE '%semi%'

-----------------------------------------------------------------------------

mysql複製過濾器：

讓從節點僅複製指定的數據庫，或指定數據庫的指定表

兩種實現方式：

1 服務器選項：主服務器僅想二進制日誌中記錄於特定數據相關的事件

注意：此項和binlog_format相關

官方文檔：https://mariadb.com/kb/en/library/mysqld-options/#-binlogignore-db

相關變量：

binlog_do_db ='db_name' 數據庫白名單列表，多個數據庫需多行實現

binlog_ingore_db='db_name' 數據庫黑名單列表

問題：基於二進制還原將沒法事項，

不建議使用此方式

2 從服務器SQL_THREAD在replay日誌中的事件時，僅讀取與特定數據庫（特定表）

相關的事件並應用於本地

問題：會形成網絡及磁盤I/O浪費

從服務器上覆制過濾相關變量：

replicate_do_db= 指定複製庫的白名單

replicate_ignore_db= 指定複製庫黑名單

replicate_do_table= 指定複製表的白名單

replicate_ignore_table= 指定複製表的黑名單

replicate_wild_do_table= foo%.bar% 支持通配符

replicate_wild_ignore_table=

mysql 複製的監控和維護：

1 清理日誌：

PURGE {BINARY|MASTER} LOGS {TO 'log_name'|BEFORE datetime_expr}

RESET MASTER;

RESET SLAVE;

2 複製監控：

SHOW MASTER STATUS;

SHOW BINLOG EVENTS;

SHOW BINARY LOGS;

SHOW SLAVE STATUS;

SHOW PROCESSLIST;

3 從服務器是否落後於主服務器

Seconds_Behind_Master: 0

4 如何肯定主從節點數據是否一致

安裝percona-tools

5 數據不一致如何修復：

刪除從數據庫，從新複製

------------------------------------------------------------------------------

mysql 加密複製：

基於SSL複製：

在默認的主從複製過程或遠程鏈接到MYSQL/mariadb全部的鏈接通訊中的

數據都是明文的，外網裏訪問數據或者複製，存在安全隱患。

經過SSL/TSL加密的方式進行復制的方法，來進一步提升數據的安全性

官方文檔：https://mariadb.com/kb/en/library/replication-with-secureconnections/

配置實現：

1 創建CA 並頒發證書

主節點證書目錄如：

tree /etc/my.cnf.d/ssl/

├── cacert.pem

├── master.crt

├── master.csr

└── master.key

從節點證書目錄如：

tree /etc/my.cnf.d/ssl/

├── cacert.pem

├── slave.crt

├── slave.csr

└── slave.key

2 主節點修改配置文件：

vim /etc/my.cnf

[mysqld]

server_id=2

log_bin

ssl

ssl-ca=/etc/my.cnf.d/ssl/cacert.pem

ssl-cert=/etc/my.cnf.d/ssl/master.crt

ssl-key=/etc/my.cnf.d/ssl/master.key

主節點添加受權帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.65.160'

IDENTIFIED BY 'centos';

查看二進制日誌position

SHOW MASTER STATUS;

mariadb-bin.000001 | 409

3 從節點配置文件：

vim /etc/my.cnf

[mysqld]

server_id=3

relay_log=relay-log

relay_log_index=relay.index

read_only=ON

添加鏈接：

CHANGE MASTER TO

MASTER_HOST='192.168.65.155',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_CONNECT_RETRY=10,

MASTER_LOG_FILE='mariadb-bin.000001',

MASTER_LOG_POS=409,

MASTER_SSL=1,

MASTER_SSL_CA = '/etc/my.cnf.d/ssl/cacert.pem',

MASTER_SSL_CERT = '/etc/my.cnf.d/ssl/slave.crt',

MASTER_SSL_KEY = '/etc/my.cnf.d/ssl/slave.key';

啓動複製：

START SLVE

4 查看鏈接狀態：SHOW SLAVE STATUS;

確保這幾行：

Master_SSL_Allowed: Yes

Master_SSL_CA_File: /etc/my.cnf.d/ssl/cacert.pem

Master_SSL_CA_Path:

Master_SSL_Cert: /etc/my.cnf.d/ssl/slave.crt

Master_SSL_Cipher:

Master_SSL_Key: /etc/my.cnf.d/ssl/slave.key

注意：有嘗試將slave節點的證書路徑放在配置文件中，

結果是，slave status中路徑不顯示，

------------------------------------------------------------------------------------------

mysql 高可用

1 Master HA或多主模型

2 MMM：multi master mysql ，基於主從複製實現

3 MHA：master high availability,對主節點進行監控，可實現自動故障轉移至其餘從

節點；經過提高某一個從節點爲新的主節點，基於主從複製實現，還須要客戶端

配合實現，目前MHA主要支持一主多從的架構，要搭建MHA,要求一個複製集羣中心

最少有3臺數據庫服務器，1主2從，即1臺充當master，一臺充當備用master，另外

一臺充當從庫，處於機器成本的考慮，淘寶進行了改造，目前淘寶TMHA已經支持一主

一從

4 galera cluster：wresp

經過wresp協議在全局實現複製，任何一個節點均可讀寫，不須要主從複製，實現

多主可讀可寫

MHA：

官方地址：https://code.google.com/archive/p/mysql-master-ha/

工做原理：

1 從宕機崩潰的master保存二進制日誌事件

2 識別含有最新更新的slave

3 應用差別的中繼日誌到其餘的slave

4 應用從master保存的二進制日誌事件

5 提高一個slave爲新的master

6 使其餘的slave鏈接新的master進行復制

MHA軟件由兩部分組成，manager工具包和node工具包

manager工具包主要包括如下幾個工具：

masterha_check_ssh 檢查MHA的SSH配置情況

 masterha_check_repl 檢查MySQL複製情況

 masterha_manger 啓動MHA

 masterha_check_status 檢測當前MHA運行狀態

 masterha_master_monitor 檢測master是否宕機

 masterha_master_switch 故障轉移（自動或手動）

 masterha_conf_host 添加或刪除配置的server信息

node工具包：這些工具一般由MHA manager的腳本觸發，無需人爲操做，

主要包括如下幾個工具：

save_binary_logs 保存和複製master的二進制日誌

apply_diff_relay_logs 識別差別的中繼日誌事件並將其差別的事件應用

於其餘的slave

filter_mysqlbinlog 去除沒必要要的ROLLBACK事件（MHA已再也不使用此工具）

purge_relay_logs 清除中繼日誌（不會阻塞SQL線程）

注意：爲了儘量的減小主庫硬件損壞形成的數據丟失，所以在配置MHA的同時建議

配置成mysql5.5的半同步複製

自定義擴展：

secondary_check_script：經過多條網絡路由檢測master的可用性

 master_ip_ailover_script：更新Application使用的masterip

 shutdown_script：強制關閉master節點

 report_script：發送報告

 init_conf_load_script：加載初始配置參數

 master_ip_online_change_script：更新master節點ip地址



配置文件：

global配置，爲各application提供默認配置

application配置：爲每一個主從複製集羣

---------------------------------------------------------------------------------

實現MHA:

實驗環境準備4臺虛擬機

主機1 192.168.65.150 manager節點

主機2 192.168.65.132 master節點

主機3 192.168.65.155 slave1

主機4 192.168.65.160 slave2

1 實現主機2,3,4之間主從複製

master節點

vim /etc/my.cnf

[mysqld]

server_id=1

log_bin

重啓服務：

記錄二進制日誌及position：

SHOW MASTER STATUS;

受權複製帳號：

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.65.%'

IDENTIFIED BY 'centos';

slave節點1和2：

vim /etc/my.cnf

[mysqld]

server_id=2

relay_log=relay-log

relay_log_index=relay,index

read_only=ON

log_bin

relay_log_purge=0

重啓服務：

添加鏈接：

CHANGE MASTER TO

MASTER_HOST='192.168.65.132',

MASTER_USER='repluser',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_CONNECT_RETRY=10,

MASTER_LOG_FILE='mariadb-bin.000001',

MASTER_LOG_POS=245;

啓動複製：

START SLAVE;

2 實現主機之間基於key驗證

主機1 ，也能夠是任意節點

ssh-keygen

ssh-copy-id 192.168.65.150

scp -r .ssh 192.168.65.132:/root/

scp -r .ssh 192.168.65.155:/root/

scp -r .ssh 192.168.65.160:/root/

3 添加mha受權帳號：

在master節點：

GRANT ALL ON *.* TO 'mhauser'@'192.168.65.%' IDENTIFIED BY 'centos';

此受權會推送至slave節點，一併添加受權帳號

4 安裝mha軟件，需啓用epel源

manager節點：

yum install mha4mysql-manager-0.56-0.el6.noarch.rpm \

mha4mysql-node-0.56-0.el6.noarch.rpm -y

其餘節點：

yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y

5 配置管理節點

mkdir -p /etc/mastermha/app1

vim /etc/mastermha/app1.cnf

[server default]

user=mhauser

password=centos

manager_workdir=/data/mastermha/app1/

manager_log=/data/mastermha/app1/manager.log

remote_workdir=/data/mastermha/app1/

ssh_user=root

repl_user=repluser

repl_password=centos

ping_interval=1

[server1]

hostname=192.168.65.132

candidate_master=1

[server2]

hostname=192.168.65.155

candidate_master=1

[server3]

hostname=192.168.65.160

6 檢查配置

在管理節點使用：

masterha_check_ssh --conf=/etc/mastermha/app1.cnf

masterha_check_repl --conf=/etc/mastermha/app1.cnf

7 啓動服務，前臺執行

masterha_manager --conf=/etc/mastermha/app1.cnf

排錯日誌：

/data/mastermha/app1/manager.log

8 若是master節點故障，mha會自動將slave1設置爲提高master節點

且退出運行

此時若是前方有調度器，應該將調度器指向slave1節點

若是主機2 即原master節點恢復，將它添加爲從服務器，重新投入使用

並從新啓動mha

若是slave1故障，主機2（原master）將會提高爲master

注意：主節點log_bin 若是在配置文件中更換路徑了，

則須要在mha配置文件中註明

master_binlog_dir=/path/to/binlog_directory_of_the_master

或者改回默認地址

-----------------------------------------------------------------------------------

Galera Cluster：

galera cluster:

集成了galera插件的mysql集羣，是一種新型的，數據不共享的，高度冗餘的高可用

方案，目前galera cluster 有兩個版本，分別是percona xtradb cluster 及

mariadb cluster，calera自己是具備多主特性的，即採用multi-master 的集羣架構，

是一種既穩健，又在數據一致性，完整性及高性能方面有出色表現的高可用解決方案

架構：

多個節點組成了一個集羣，與普通的主從架構不一樣，它們均可以作做爲主節點，三個

節點是對等的，稱爲multi-master架構，當有客戶端要寫入或者讀取數據時，鏈接哪

個實例都是同樣的，讀到的數據是相同的，寫入某一個節點以後，集羣本身會將新數據

同步到其餘節點上面，這種架構不共享任何數據，是一種高冗餘架構

Galera Cluster特色：

多主架構：

真正的多點讀寫的集羣，在任什麼時候候讀寫數據，都是最新的。

同步複製：

集羣不一樣節點之間的數據同步，沒有延遲，在數據庫掛掉以後，數據不會丟失

併發複製：

從節點apply數據時，支持並行執行，更好的性能

故障切換：

在出現數據庫故障時，因支持多點寫入，切換容易

熱插拔：

在服務期間，若是數據庫掛了，只要監控程序發現的夠快，不可服務的時間就會

很是少，在節點故障期間，節點自己對集羣的影響很是小

自動節點克隆：

在新增節點，或者停機維護時，增量數據或者基礎數據不須要人工手動備份提供

galera cluster 會自動拉取在線節點數據，最終集羣會變爲一致

對應用透明：

集羣的維護，對應用程序是透明的

官方文檔：

http://galeracluster.com/documentation-webpages/galera-documentation.pdf

http://galeracluster.com/documentation-webpages/index.html

https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/

包括兩個組件

 Galera replication library (galera-3)

 WSREP：MySQL擴展Write Set Replication API



wresp複製實現：

 percona-cluster

 MariaDB-Cluster



注意：都至少須要三個節點，不能安裝mariadb-server

安裝galera cluster：

配置yum源：

官方rpm：https://downloads.mariadb.org/mariadb/repositories/#mirror=host-europe

[mariadb]

name = MariaDB

baseurl = http://yum.mariadb.org/5.5/centos7-amd64

gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB

gpgcheck=1

清華yum源

[mariadb]

name = MariaDB-qinghua

baseurl = https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.60/yum/centos7-amd64/

gpgcheck=0

安裝：

yum install MariaDB-Galera-server -y

實現Galera cluster：

1 修改配置文件,三臺主句分別完成相同配置

vim /etc/my.cnf.d/server.cnf

wsrep_provider = /usr/lib64/galera/libgalera_smm.so

wsrep_cluster_address="gcomm://192.168.65.132,192.168.65.155,192.168.65.160"

binlog_format=row

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2

bind-address=0.0.0.0

下面配置可選項

wsrep_cluster_name = ‘mycluster ‘默認my_wsrep_cluster

wsrep_node_name = 'node1'

wsrep_node_address = ‘172.16.0.7'

注意： /usr/lib64/galera/libgalera_smm.so 由galera-25.3.23-1包提供，yum關聯安裝上的

2 啓動服務：

首次啓動時，須要初始化集羣，在其中一個節點上執行命令：

/etc/init.d/mysql start --wsrep-new-cluster

然後正常啓動其餘節點：

service mysql start

3 查看集羣中相關係統變量和狀態變量

SHOW VARIABLES LIKE 'wsrep_%‘;

SHOW STATUS LIKE 'wsrep_%‘;

SHOW STATUS LIKE 'wsrep_cluster_size‘;

-----------------------------------------------------------------------------------

mysql複製的問題和解決方案：

1 數據損壞或丟失

Master： MHA + semi repl

slave: 從新複製

2 混合使用存儲引擎

MyISAM:不支持事務

InnoDB:支持事務

3 不惟一的server id

從新複製

4 複製延遲

須要額外的監控工具的輔助

一從多主： mariadb10版後支持

多線程複製：對多個數據庫複製

性能衡量指標：

數據庫服務衡量指標：

qps: query per second

tps: transaction per second



壓力測試工具：

 mysqlslap

 Sysbench：功能強大

https://github.com/akopytov/sysbench

 tpcc-mysql

 MySQL Benchmark Suite

 MySQL super -smack

 MyBench

mysql 壓力測試：

Mysqlslap：來自於mariadb包，測試的過程默認生成一個mysqlslap的

schema,生成測試表t1，查詢和插入測試數據，mysqlslap庫自動生成，若是已

經存在則先刪除。用--only-print來打印實際的測試過程，整個測試完成後不會

在數據庫中留下痕跡



使用格式：

mysqlslap [options]

 經常使用參數 [options] 說明：

 --auto-generate-sql, -a

自動生成測試表和數據，表示用mysqlslap工具本身生成的SQL腳原本測試併發壓力

 --auto-generate-sql-load-type=type

測試語句的類型。表明要測試的環境是讀操做仍是寫操做仍是二者混合的。取值包括：read，key，write，

update和mixed(默認)

--auto-generate-sql-add-auto-increment

表明對生成的表自動添加auto_increment列，從5.1.18版本開始支持

--number -char -cols=N, -x N

自動生成的測試表中包含多少個字符類型的列，默認1

--number -int -cols=N, -y N

自動生成的測試表中包含多少個數字類型的列，默認1

--number -of -queries=N

總的測試查詢次數(併發客戶數×每客戶查詢次數)

--query=name,-q

使用自定義腳本執行測試，例如能夠調用自定義的存儲過程

或者sql語句來執行測試

--create-schema

表明自定義的測試庫名稱，測試的schema，MySQL中

schema也就是database

--commint=N

多少條DML後提交一次

--compress, -C

如服務器和客戶端都支持壓縮，則壓縮信息

--concurrency=N, -c N

表示併發量，即模擬多少個客戶端同時執行select。

可指定多個值，以逗號或者--delimiter參數指定值作爲分隔符

如：--concurrency=100,200,500

--engine=engine_name, -e engine_name

表明要測試的引擎，能夠有多個，用分隔符隔開。

例如：--engines=myisam,innodb

--iterations=N, -i N

測試執行的迭代次數，表明要在不一樣併發環境下，各自運行測試多少次

--only-print

只打印測試語句而不實際執行。

--detach=N

執行N條語句後斷開重連

--debug-info, -T

打印內存和CPU的相關信息

mysqlslap示例：

單線程測試

mysqlslap -a -uroot -pmagedu



多線程測試。使用–concurrency來模擬併發鏈接

mysqlslap -a -c 100 -uroot -pmagedu



迭代測試。用於須要屢次執行測試獲得平均值

mysqlslap -a -i 10 -uroot -pmagedu

mysqlslap ---auto-generate-sql-add-autoincrement -a

mysqlslap -a --auto-generate-sql-load-type=read

mysqlslap -a --auto-generate-secondary-indexes=3

mysqlslap -a --auto-generate-sql-write-number=1000

mysqlslap --create-schema world -q "select count(*) from City」

mysqlslap -a -e innodb -uroot -pmagedu

mysqlslap -a --number -of -queries=10 -uroot -pmagedu

測試同時不一樣的存儲引擎的性能進行對比

mysqlslap -a --concurrency=50,100 --number -of -queries 1000

--iterations=5 --engine=myisam,innodb --debug-info -uroot -pmagedu



執行一次測試，分別50和100個併發，執行1000次總查詢

mysqlslap -a --concurrency=50,100 --number -of -queries 1000

--debuginfo -uroot -pmagedu



50和100個併發分別獲得一次測試結果(Benchmark)

併發數越多，執行完全部查詢的時間越長。

爲了準確起見，能夠多迭代測試幾回

mysqlslap -a --concurrency=50,100 --number -of -queries 1000

--iterations=5 --debug-info -uroot -pmagedu

生產環境my.cnf配置示例：

硬件：內存32G

innodb_file_per_table = 1

打開獨立表空間

max_connections = 8000

#MySQL 服務所容許的同時會話數的上限，常常出現Too Many Connections的錯誤提

示，則須要增大此值

ack_log = 300

#back_log 是操做系統在監聽隊列中所能保持的鏈接數

max_connect_errors = 1000

#每一個客戶端鏈接最大的錯誤容許數量，當超過該次數，MYSQL服務器將禁止此主機的連

接請求，直到MYSQL服務器重啓或經過flush hosts命令清空此主機的相關信息

open_files_limit = 10240

#全部線程所打開表的數量

max_allowed_packet = 32M

#每一個鏈接傳輸數據大小.最大1G，須是1024的倍數，通常設爲最大的BLOB的值

wait_timeout = 10

#指定一個請求的最大鏈接時間

sort_buffer_size = 16M

# 排序緩衝被用來處理相似ORDER BY以及GROUP BY隊列所引發的排序

join_buffer_size = 16M

#不帶索引的全表掃描.使用的buffer的最小值

query_cache_size = 128M

#查詢緩衝大小

query_cache_limit = 4M

#指定單個查詢可以使用的緩衝區大小，缺省爲1M

transaction_isolation = REPEATABLE-READ

# 設定默認的事務隔離級別

thread_stack = 512K

# 線程使用的堆大小. 此值限制內存中能處理的存儲過程的遞歸深度和SQL語句複雜性，

此容量的內存在每次鏈接時被預留.

log-bin

# 二進制日誌功能

log_long_format=row

#二進制日誌格式

innodb_buffer_pool_size = 6G

#InnoDB使用一個緩衝池來保存索引和原始數據, 可設置這個變量到服務器物理內存大小

的80%

innodb_file_io_threads = 4

#用來同步IO操做的IO線程的數量

innodb_thread_concurrency = 16

#在InnoDb核心內的容許線程數量，建議的設置是CPU數量加上磁盤數量的兩倍

innodb_log_buffer_size = 16M

# 用來緩衝日誌數據的緩衝區的大小.

innodb_log_file_size = 512M

在日誌組中每一個日誌文件的大小.

innodb_log_files_in_group = 3

# 在日誌組中的文件總數

innodb_lock_wait_timeout = 120

# SQL語句在被回滾前,InnoDB事務等待InnoDB行鎖的時間

long_query_time = 2

#慢查詢時長

log-queries-not -using-indexes

#將沒有使用索引的查詢也記錄下來

MYSQL配置最佳實踐：

高併發大數據的互聯網業務，架構設計思路是「解放數據庫CPU，將計算轉移

到服務層」，併發量大的狀況下，這些功能極可能將數據庫拖死，業務邏輯放

到服務層具有更好的擴展性，可以輕易實現「增機器就加性能」

參考：

阿里巴巴Java開發手冊

58到家數據庫30條軍規解讀

http://zhuanlan.51cto.com/art/201702/531364.htm

筆記整理完成時間：2018年6月24日23:04:00

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。