mysql運維日記

mysql半同步複製
　　半同步的特性
　　　　收到ack或者超時關閉半同步
　　　　從庫只有將binlog flush到repay log纔會給主庫的等待線程發送ack
　　　　超時轉換爲異步複製後，當至少一個半同步從節點遇上來是，主庫便會自動轉換爲半同步複製
　　　　半同步必須在主從庫上都是打開的狀態，不然便爲異步複製

　　　　相較於異步複製,半同步變慢時間至少是TCP/IP一次發送與接收所用的時間(多IDC部署本地至少有一個slave)
　　半同步主庫端
　　　　after_flush -- 最後一個event才須要發送ACK
　　　　after_sync -- 從庫數據可能會多餘主庫數據
　　　　after_commit -- 從庫會丟數據，主庫是commit後再等待
　　　　after_rollback -- 同after_commit
　　　　transmit_start -- 發送binlog以前作判斷，全部等待這個點的主庫線程均可以不等了，直接commit
　　　　transmit_stop -- 主庫想從庫發送完binlog結束以後
　　　　defore_send_event -- 發送binlog以前，是否須要從庫發送ACK信息
　　　　after_send_event -- binlog發送完成以後，
　　　　after_reset_master -- reset_master語句執行以後
　　半同步從庫端
　　半同步實現
　　插件安裝
　　半同步自動開關

MySQL5.7多線程複製
　　延遲優化方法
　　　　增長buffer_pool的大小、緩存更多數據，減小IO壓力
　　　　增大log_buffer_size及group，減小buffer_pool的刷盤IO，提高寫入性能
　　　　修改flush_method爲O_DIRECT，提高寫入性能
　　　　若是能夠的話，關掉從庫binlog，或者log_slave_uodates
　　　　修改參數innodb_flush_log_at_trx_commit爲0或者2
　　　　若是沒有關掉binlog，修改參數sync_binlog爲0或者更大的數，減小IO的壓力
　　MySQL5.6多線程複製
　　　　1.數據庫比較多
　　　　2.每一個數據庫的寫入比較均勻
　　　　由於MySQL5.6複製分發級別設置的是庫
　　MySQL5.7多線程複製
　　　　全部處於prepare階段的事務均可以並行提交
　　　　　　last_commit

　　　　ordered commit

　　　　　　flush:stage #1 flushing trans to bin log 

　　　　　　　　binlog寫入文件

　　　　　　　　寫入成功後通知dump線程dump binlog發送給slave

　　　　　　sync:stage #2 syncing binlog file to disk

　　　　　　commit:stage #3 commit all trans in order.（取決於參數binlog_order_commits設置）

　　多線程複製分發原理

　　　　比較last_commit與sequence_number

　　異常故障恢復

　　　　1.找到連接主庫的信息-- slave_master_info

　　　　2.找到複製位置及線程個數  -- slave_relay_log_info

　　　　3.找到每一個線程的複製信息 -- slave_worker_info

 

大量MySQL表致使複製變慢的問題

　　performance_schema_max_file_instances=open_file_limit/0.65   

快速刪除大表

　　buffer pool mutex

　　flush list mutex

　　經過建立硬連接的方式刪除ibd文件 --分塊truncate os大文件

　　galera cluster的處理

　　　　單實例set @@session.wsrep_on=off;ln硬連接;drop table xxx；  -- 循環全部實例

兩條不一樣的插入語句致使的死鎖

　　環形死鎖

　　惟一索引，聯合惟一索引

　　隔離級別

　　gap鎖

MySQL在併發刪除同一行數據時致使死鎖的分析

　　併發數

　　隔離級別

　　業務控制

參數sql_slave_skip_counter的奧祕

　　sql_slave_skip_counter=1，跳過整個事務，多個事件，有可能包含多個dml，跳事後肯定是否須要修補數據

　　sql_slave_skip_counter>1，跳過一個事件減1，不可控

binlog中的時間戳

 InnoDB中Rowid對binlog的影響

　　Rowid是存儲引擎層的東西 ，不會記錄到binlog中

MySQL備份：Percona Xtrabackup的原理與實踐

　　備份背景及類型

　　認識percona Xtrabackup

　　Xtrabackup的工做流程

　　　　innobackupex   fork Xtrabackup備份innodb文件

　　　　　　兩種線程

　　　　　　　　ibd複製線程

　　　　　　　　redo log複製線程  --最近checkpoint

　　　　檢測文件喚醒innobackupex進程

　　　　innobackupex執行備份鎖(lock table for backup),取得一致性位點，開始備份非innodb文件

　　　　innobackupex開始執行lock binlog for backup,獲取binlog位置

　　　　建立Xtrabackup_binlog_info,寫入位點信息

　　　　後續工做

　　Xtrabackup的備份原理

　　　　lock tables for backup與flush tables with read lock的區別

　　　　xtrabackup_binlog_info與xtrabackup_slave_info區別

　　Xtrabackup所需權限

　　innobackupex經常使用備份選項說明

MySQL分庫分表

　　分庫分表的種類

　　　　表分區

　　　　垂直拆分

　　　　　　單實例拆分紅多實例

　　　　　　字段多，能夠獨立拆分出來

　　　　水平拆分

　　分庫分表的原則

　　　　原則零:能不分則不分

　　　　原則一：正常的運維影響正常的業務訪問

　　　　　　數據庫備份

　　　　　　表修改

　　　　　　熱點數據頻繁訪問  --水平拆分，減小鎖粒度

　　　　原則二：表設計不合理，須要對某些字段進行垂直拆分

　　　　原則三：某些數據表出現無窮增加的狀況

　　　　原則四：安全性和可用性的考慮

　　　　原則五：業務耦合性考慮

　　分庫分表實現

　　　　數據庫層的實現

　　　　　　replication

　　　　　　觸發器

　　　　業務層的實現

MySQL數據安全

　　單機安全

　　　　進程奔潰

　　　　主機宕機

　　　　恢復機制：undo、redo

　　　　磁盤數據完整性：doublewrite

　　　　日誌刷盤策略：innodb_flush_log_at_trx_commit

　　集羣安全

　　　　服務器硬件或操做系統故障，系統沒法重啓

　　　　原生replication

　　　　第三方插件：galera

　　備份安全

　　　　時效性

　　　　恢復時間最小化：針對Xtrabackup作好apply_log

　　　　備份可用性：apply_log

　　MySQL實例安全保證

　　　　doublewrite:針對頁面寫失敗，致使沒法重啓

　　　　redo log：crash recover

　　　　　　innodb_flush_log_at_trx_commit

 　　　　　　　　0:每隔1秒刷一次，刷到文件

　　　　　　　　 1:每次提交都寫文件，刷盤

　　　　　　　　  2:每次提交都寫文件，不刷盤，每隔1秒刷一次盤

　　　　宕機與innodb_flush_log_at_trx_commit的關係

　　　　　　1.進程掛掉，os正常

　　　　　　　　0：丟一秒

　　　　　　　　1：不丟失

　　　　　　　　2：os刷盤，不丟失

　　　　　　2.主機宕機

　　　　　　　　0：丟一秒

　　　　　　　　1：不丟失

　　　　　　　　2：丟一秒

　　MySQL集羣安全

　　　　sync_binlog

　　　　　　0:事務提交時，binlog寫入文件(OS cache)不刷盤，主機不宕機不丟失

　　　　　　1:事務提交時都會刷盤

　　　　　　N：每N次事務提交，MySQL調用文件系統的刷新操做刷盤，主機宕機或服務掛掉都有可能丟失一些事務

　　　　兩階段提交（innodb_support_xa）

　　　　　　prepare階段：告訴InnoDB引擎作prepare，innodb更改事務狀態，並將redo log刷入磁盤

　　　　　　commit階段：先記錄binlog，而後commit

　　　　主從複製參數的影響

　　　　　　binlog_format

　　　　　　master_info_repository與sync_master_info

　　　　semi_Syng_replication方式複製
　　　　　　參數
　　　　　　　　rpl_semi_sync_master_wait_point
　　　　　　　　　　after_commit：commit後等待ACK，主庫宕機，slave可能丟數據
　　　　　　　　　　after_sync：接收到ACK後再commit，slave可能多數據
　　　　MySQL集羣化如何保證數據庫安全
　　　　　　galera cluster
　　　　　　　　多線程的並行複製，自帶節點管理機制，主動監測集羣節點狀態，自動管理有問題的數據節點，多點寫入和平滑擴容
　　　　　　　　全部的表都必須是innodb表
　　　　　　　　參數設置
　　　　　　　　　　innodb_doublewrite=on
　　　　　　　　　　innodb_flush_log_at_trx_commit=0
　　　　　　　　　　sync_binlog=0
　　　　　MGR
　　　　　　　　innodb_doublewrite=on
　　　　　　　　innodb_flush_log_at_trx_commit=0
　　　　　　　　binlog-format=row
　　　　　　　　master-info_repository=table
　　　　　　　　relay-log-info-repository=table
MySQL性能拾遺
　　適當的數據文件大小
　　碎片空洞問題
　　　　show table status data_length/data_free optimize table table_name/alter table table_name engine=innodb重建表空間;

 　　設計問題

　　　　1.字段的合理設置

　　　　　　最小的也是最有效的，

　　　　　　ip無符號整形數字，

　　　　　　not null：不須要逐個值去判斷是否爲null，每一個字段會節省1bit的空間

　　　　2.行存儲格式

　　　　　　若是空間有問題，能夠選擇compact

　　　　3.索引問題

　　 合理設計表結構

　　　　冗餘存儲

　　　　　　查詢某人的好友，訂單信息

　　　　　　查詢特別好友

　　　　拆分存儲

　　　　重複存儲

　　正確使用索引

　　　　1.最左匹配原則

　　　　2.計算列沒法使用索引

　　　　3.否認條件不能使用索引

　　　　4.join鏈接的字段類型不一致，表的字符集不一致，也不能使用索引

　　　　5.覆蓋索引

　　　　6.其餘

　　MySQL系統參數

　　　　general_log

　　　　query_cache_size

　　　　sort_buffer_size

　　　　join_buffer_size

　　　　tmp_table_szie

　　　　innodb_buffer_pool_size

　　　　innodb_buffer_pool_instances

　　　　innodb_log_file_size

　　　　innodb_log_files_in_group

　　　　innodb_numa_interleave   -- 0,1,2

　　　　innodb_old_blocks_pct

　　　　innodb_old_blocks_time

　　　　innodb_autoinc_lock_mode

　　　　innodb_flush_method

　　　　innodb_doublewrite

　　　　innodb_io_capacity

　　　　innodb_thread_concurrency

　　　　inndb_flush_log_at_trx_commit

　　　　sync_binlog

　　　　binlog_format

　　　　binlog_order_commits

　　　　tx_isolation

　　　　slave_parallel_workers

　　內存和cpu

　　　　cpu  cores 主頻

　　　　內存  SQL優化

　　磁盤的革命               -- raid10 raid5 r/s  順序 隨機 存儲 讀取 緩存 flash SSD

　　　　SSD基本概念

　　　　SSD優越性

 MGR

　　GR概述

　　組的概念

　　　　建立組：當組的第一個成員啓動時，須要對組進行初始化

　　　　加入組

　　　　離開組

　　多組複製

　　單獨的通訊機制

　　　　獨立的端口傳輸binlog

　　group replication服務模式

　　　　單主模式

　　　　　　主成員的自動選取和切換

　　　　　　讀寫模式的自動切換

　　　　　　failover：從其餘成員查詢到主成員的UUID

　　　　多主模式

　　　　　　自增字段的處理

　　　　　　　　1.直接經過系統變量來配置

　　　　　　　　　　auto_increment_increment

　　　　　　　　　　auto_increment_offset

　　　　　　　　2.經過插件配置

　　　　　　　　　　group_replication_auto_increment_increment

　　　　　　　　　　段大小設置

　　　　　　多主模式的限制

　　　　　　　　不支持串行化的隔離級別

　　　　　　　　不支持外鍵級聯的操做

　　　　　　限制的檢查

　　　　　　　　group_replication_enforce_update_everywhere_checks = true

　　　　　　DDL語句併發執行的問題

　　　　　　對多主模式在使用上的一些思考

　　　　　　　　能夠看成單主來用

　　　　服務模式的配置

　　　　　　group_replication_single_primary_mode=OFF

　　　　　　默認是單主模式，若是要使用多主，在別的成員加入主前，設置該參數爲OFF，這個參數不能在線修改

　　binlog event的多線程執行

　　　　group_replication_applier通道

　　　　　　start slave sql_thread for channnel 'group_replication_applier'

　　　　　　stop slave sql_thread for channnel 'group_replication_applier'

　　　　基於主鍵的並行執行

　　　　　　set global slave_parallel_type='logical_clock'

　　　　　　set global slave_parallel_workers=N

　　　　　　set global slave_preserve_commit_order=ON

　　搭建GR複製環境

　　　　MySQL的參數設置

　　　　　　開啓binlog和relaylog

　　　　　　　　server_id=1

　　　　　　　　log_bin=binlog

　　　　　　　　log_slave_updates = on

　　　　　　　　relay_log=relay-log

　　　　　　開啓GTIT功能

　　　　　　　　gtid_mode=on

　　　　　　　　enforce_gtid_consistency=on

　　　　　　設置row格式的binlog

　　　　　　禁用binlog_checksum

　　　　　　使用系統表來存儲slave信息

　　　　　　開啓並行複製

　　　　　　開啓主鍵信息採集功能

　　　　GR插件的使用

　　　　　　加載插件

　　　　　　啓用插件

　　　　　　停用插件

　　　　GR插件的基本參數設置

　　　　　　設置組的名字

　　　　　　設置成員的本地地址

　　　　　　設置種子成員的地址

　　　　　　設置成員ip白名單

　　　　　　將參數寫入配置文件

　　　　group replication的數據庫用戶

　　　　　　_gr_user@localhost用戶

　　　　　　root用戶

　　　　group replication組初始化

　　　　　　組初始化特有的參數

　　　　　　組初始化的步驟

　　　　新成員加入組

　　　　　　配置group_replication_recovery通道

　　　　　　成員加入組的步驟

　　group replication的高可用性

　　　　組內成員數量變化

　　　　強制移除故障成員

　　group replication的監控

　　group replication基本原理

　　　　狀態機複製

　　　　分佈式的狀態機複製

　　　　分佈式的高可用數據庫

　　深刻理解group replication中事務的執行過程

　　　　本地事務控制模塊

　　　　　　發送事務信息

　　　　　　等待全局事務認證模塊的認證結果

　　　　　　認證結果的處理

　　　　成員間的通訊模塊

　　　　

MySQL Document Store

　　新的json數據類型和json函數

　　　　json數據類型

　　　　json函數

　　　　　　json_extract