MySQL運維進階-MySQL雙主(master-master)+半同步(Semisync Repl
MySQL: oracle ,
commutity : 社區版 5.5 5.6 5.7 8.0
MariaDB:
5.5 10.x
Percona:
Percona-Server
InnoDB --> XtraDB
Xtrabackup
percona-tools:
存儲引擎：
引擎：也稱為表類型，表級別概念，不建議在同一個庫中的表上使用不同的ENGINE；
CREATE TABLE ... ENGINE STORAGE_ENGINE_NAME ...
SHOW TABLE STATUS
常見的存儲引擎： SHOW ENGINES; MyISAM, Aria, InnoDB, MRG_MYISAM, CSV, BLACKHOLE,... InnoDB : InnoBase Percona-XtraDB,Supports transactions , row-level locking, and foreign keys 數據存儲於“表空間” 中： （1）所有數據庫中的所有類型為InnoDB的表的數據和索引存儲於同一個表空間中； 表空間文件：datadir定義的目錄中，文件 ibdata1,ibdata2... (2) innodb_file_per_table=ON,意味著每表使用單獨的表空間文件; 每表的數據文件（數據和索引，存儲於數據庫目錄）存儲於自己專用的表空間文件中，並存儲於數據庫目錄下：tablename.ibd 表結構的定義：在數據庫目錄，tablename.frm 事務型存儲引擎，適合對事物要求較高的場景中；但較適用於處理大量短期事務； 基於MVCC（Mutil Version Concurrency Control）支持高並發；支持四個隔離級別，默認級別為 REPETABLE-READ(可重讀-幻讀); 間隙鎖以防止幻讀：（MVCC多版本控制就是解決了幻讀問題） 使用聚集索引（主鍵索引）；支持“自適應Hash索引”； 鎖粒度： 行級鎖，間隙鎖 總結： 數據存儲：表空間； 並發：MVCC，間隙鎖，行級鎖 索引：聚集索引、輔助索引； 性能：預讀操作、內存數據緩沖、內存索引緩存、自適應Hash索引、插入操作緩存區； 備份：支持熱備； SHOW ENGINE INNODB STATUS；
MyISAM：-> Aria
支持全文索引（FULLTEXT index）、壓縮、空間函數（GIS）； 不支持事務 鎖粒度：表級鎖 崩潰後無法保證表安全恢復 適用場景：只讀或讀多寫少的場景、較小的表（以保證崩潰後恢復的時間較短）； 文件：每個表有三個文件，存儲於數據庫目錄中 tbl_name.frm：表格式定義； tbl_name.MYD：數據文件； tbl_name.MYI：索引文件； 特性： 加鎖和並發：表級鎖； 修復：手動或自動修復、但可能會丟失數據； 索引：非聚集索引； 延遲索引更新； 表壓縮； 顯示鎖的使用： 1）LOCK TABLES LOCK TABLES tb1_name read|write... UNLOCK TABLES; 2）FLUSH TABLES; FLUSH TABLES tb1_name,.... [WITH READ LOCK]; UNLOCK TABLES; 3) SELECT cluase [FOR UPDATE | LOCK IN SHARE MODE] 事務： 事務：一組原子性的SQL查詢、或者是一個或多個SQL語句組成的獨立工作 單元： 事務日誌： innodb_log_files_in_group innodb_log_group_home_dir innodb_log_file_size innodb_mirrored_log_groups ACID測試： A：AUTOMICITY，原子性，整個事務中的所有操作要麽全部成功執行，要麽失敗後回滾； C：CONSISTENCY，一致性，數據庫總是應該從一個一致性狀態轉為另一個一致性狀態； I：ISOLATION ,隔離性， 一個事務所做出的操作在提交之前，是否能為其他事務可見；處於保證並發操作之目的，隔離有多種級別； D：DURABILITY, 持久性； 事務一旦提交，其所做出的修改會永久保存； 自動提交；單語句事務 mysql > SELECT @@autocommit; mysql > SET @@session.autocommit=0; 關閉當前會話自動提交 手動控制事務： 啟動：START TRANSACTION 提交：COMMIT 回滾：ROLLBACK 事務支持savepoints: SAVEPOINT identifier ROLLBACK [WORK] TO [SAVEPOINT] identifier RELEASE SAVEPOINT identifier 事務隔離級別：完全理解 READ-UNCOMMITIED :讀未提交 --> 臟讀問題 READ-COMMITIED: 讀提交 -->不可重復讀； REPEATABLE-READ : 可重復度 --> 幻讀問題； 默認級別 SERIALIZABLE :串行化； mysql > SELECT @@session.tx_isolation; mysql > SHOW ENGINE innodb STATUS; MySQL用戶和權限管理 用戶賬號： user@host user : 賬戶名稱； host : 此賬戶可通過哪些客戶端主機請求創建連接線程； % ： 任意長度的任意字符； _ : 任意單個字符； skip_name_resolve=ON 重命名：RENAME USER RENAME USER old_user TO new_user [,old_user TO new_user] ... 刪除用戶： DROP USER ‘username‘@‘host‘ [,‘username1‘@‘host‘]... FLUSH PRIVILEGES; 修改用戶密碼： 1）SET PASSWORD [FOR ‘username‘@‘host‘] =PASSWORD(‘string‘); 2) UPDATE mysql.user SET password=PASSWORD(‘string‘) WHERE user=‘username‘ AND host=‘HOST‘; 3) mysqladmin -uUSERNAME -hHOST -p password ‘NEW_PASS‘ 4) FLUSH PRIVILEGES;
忘記管理員密碼的解決辦法：
1） 啟動mysqld進程時，使用 --skip-grant-tables和--skip-networking選項
Centos 7 : mariadb.service
Centos 6 : /etc/init.d/mysqld
2) 通過UPDATE命令修改管理員密碼；
3) 以正常方式啟動mysqld進程；
查看授權： SHOW GRANTS; SHOW GRANTS [FOR ‘username‘@‘host‘ ]; 取消授權： REVOKE REVOKE priv_type on priv_level FROM ‘user‘@‘host‘ ... REVOKE ALL PRIVILEGES ,GRNAT OPTION FROM user..
查詢緩存相關的服務器變量：
query_cache_limit : 能夠緩存的最大查詢結果；（單語句結果集大小上限）
有著較大結果集的語句：顯示使用SQL_NO_CACHE，以避免先緩存再移出；
query_cache_min_res_unit :內存緩存塊的最小分配單位；緩存過小的查詢結果集會浪費內存空間；
較小的值會減少空間浪費，但是會導致更頻繁的內存分配以及回收操作； 較大值的會帶來空間浪費；
query_cache_size : 查詢緩存空間的總共可用的大小；單位是字節, 必須是1024的整數倍；
query_cache_type: 緩存功能啟用與否；
ON:啟用； OFF ：禁用
DEMAND: 按需緩存，僅緩存SELECT語句中帶SQL_CACHE的查詢結果；
query_cache_wlock_invalidate : 如果某表被其他連接鎖定，是否仍然可以從查詢緩存中返回查詢結果；默認為 OFF，表示可以；ON則表示不可以；
狀態變量：
mysql>SHOW GLOBAL STATUS LIKE ‘Qcache%‘;
命中率： Qcache_hits/Com_selectMySQL日誌：
1）二進制日誌
用於記錄引起數據改變或存在引起數據改變的潛在可能性的語句或改變後的結果，也可能是二者混合；
功用：重放
binlog_format=(STATEMENT|ROW|MIXED)
STATEMENT: 語句；
ROW : 行；
MIXED: 混編；
查看二進制日誌文件列表：
SHOW MASTER|BINARY LOGS;
查看當前正在使用的二進制日誌文件：
SHOW MASTER STATUS;
查看二進制日誌文件中的事件：
SHOW BINLOG EVENTS [IN ‘log_name’] [FROM pos][LIMIT [offset,] row_count]
服務器變量：
log_bin=/PATH/TO/BIN_LOG_FILE |OFF
session.sql_log_bin={ON | OFF}
控制某會話中的“寫‘’操作語句是否會被記錄到二進制日誌文件中；
max_binlog_size=
sync_binlog={1|0} ：默認是0，此時mysql性能最好，但是也是最危險的，一旦發生崩潰，存在內存緩存中的語句信息將丟失，1是最安全的也是最慢的，幾乎將二進制內存緩存信息與磁盤實時同步刷新； 可以定義N次，每執行多少次事務後刷新緩存到磁盤中
mysqlbinlog: 客戶端程序
YYYY-MM-DD hh:mm:ss
--start-datetime=
--stop-datetime=
-j, --start-position=
--stop-position=
--user, --host, --password中繼日誌：從服務器上記錄下來從主服務器的二進制日誌文件同步過來的事件；
事務日誌：事務型存儲引擎innodb用於保證事務特性的日誌文件
redo log
undo log
備份策略：
xtrabackup:
全量+差異+binlog
全量+增量+binlog
mysqldump:
全量+binlog
基於lvm2的備份：
前提：要求數據文件和事務日誌位於同一個邏輯卷：
1）請求鎖定所有表：
mysql > FLUSH TABLES WITH READ LOCK;
2) 記錄二進制文件事件位置：
mysql > FLUSH LOGS;
mysql > SHOW MASTER STATUS;
mysql -e ‘SHOW MASTER STATUS;‘ >> /PATH/TO/SOME_POS_FILE
3)創建快照卷
lvcreate -s -L 100M -p r -n SNAP-NAME /dev/VG-name/lv-name
4) 釋放鎖
mysql > UNLOCK TABLES;
5) 掛載快照卷，並執行備份，備份完成後刪除快照卷；
6) 周期性備份二進制日誌；Xtrabackup:
備份 --> 應用日誌 --> 還原
應用日誌： --apply-log
還原： --copy-back
完全備份： 完全+binlog(總結):
備份： 完全+增量+binlog...
準備：
innobackupex --apply-log --redo-only BASEDIR
innobackupex --apply-log --redo-only BASEDIR --incremental-dir=INCREMENTTAL-DIR
恢復：
innobackupex --copy-back BASEDIR
備份單庫：
--databases;
總結：
mysqldump+binlog
lvm2+cp/tar+binlog
xtrabackup(innodb)+binlog實驗【mysql主從復制架構與進階】：
MySQL雙主(master-master)+半同步(Semisync Replication)
一、環境
主機名 主機IP
mysqlA 172.18.252.221
mysqB 172.18.252.222
操作系統： CentOS 6.5 2.6.32-431.el6.x86_64
MySQL版本 mysql-community-server-5.7.5-0.6.m15.el6.x86_64
二、架構
1.mysqlA和mysqlB互為主備，即雙主架構Master-Master
MySQL運維進階-MySQL雙主(master-master)+半同步(Semisync Repl