查看glibc版本
ldd --version

--mysql啟動失敗,嘗試啟動
1 查看錯誤日志,端口被占用,參數名寫錯,有不支持的參數
2 通過mysqld啟動 mysqld --default-file=my.cnf &
3 mysqld --no-defaults --basedir=/user/local/mysql --datadir=/data/mysql/3306/data/ --user=mysql
4 strace查看mysql啟動過程的系統調用情況

查看當前用戶
select user();

系統表中注冊已加載的組件
rpm包安裝的軟件默認加載了validate_password
show plugins;
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS;
select * from mysql.component;
show variables like 'validate_password%';

加載validate_password
mysql5.7?
install plugin validate_password soname 'validate_password.so';
vi /etc/my.cnf
plugin-load=validate_password.so

mysql8.0
install component 'file://component_validate_password';

--參數
--查看參數的信息
select * from variables_info limit 1 \G
default_authentication_plugin:默認的密碼認證插件
master_info_repository:復制的相關信息保存在文件還是表里(mysql.slave_master_info,mysql.slave_relay_log_info)
gtid_mode=on
enforce_gtid_consistency=on

--錯誤
--mysql8.0以下的客戶端連接mysql8.0報錯
Authentication plugin ‘caching_sha2_password‘ cannot be loaded
原因:mysql8 之前的版本中加密規則是mysql_native_password,而在mysql8之后,加密規則是caching_sha2_password。
解決方法:
1 升級mysql客戶端或驅動
2 將參數default_authentication_plugin設置為mysql_native_password
3 創建用戶時指定auth_plugin為mysql_native_password
create user user1@'%' identified with mysql_native_password 'xxxxx';
創建用戶不指定密碼認證插件,實際上被默認指定

--主從復制
mysql8.0要加 get_master_public_key=1 ,主要是由于復制用戶使用新的密碼認證插件
change master to ?master_host='xxx', master_port=xxx, master_user='xxx', master_password='xxxx', get_master_public_key=1,master_log_file='binlog.000003',master_log_pos=155 for channel 'channel_201_3306';
基于gtid復制
change master to ?master_host='xxx', master_port=xxx, master_user='xxx', master_password='xxxx', master_auto_position=1;

?
--數據字典
mysql.slave_master_info ?保存連接主庫的信息,IO線程讀取主庫binlog信息(非實時,寫入sync_master_info參數個事務后更新)
mysql.slave_relay_log_info ?sql線程重放relay_log的位置

--查看binlog事件
show binlog events in 'mysql-bin.000001';?

--查看全局變量
show global variables like 'gtid_executed';

============================延遲復制============================
暫停SQL線程應用,并不會暫停IO線程接受日志
在主庫執行后,要等待若干秒才在備庫執行
===============使用場景:
1 應對主庫的誤操作,比如drop table
delete,update誤操作,如果日志格式是ROW,可通過binlog閃回恢復.drop操作binlog只記錄原生SQL,無法使用工具恢復
2 查看數據的歷史狀態
3 人為模擬主從延遲
也可使用flush tables with read lock模擬來模擬延遲
===============開啟延遲復制
CHANGE MASTER TO master_host='xxxxx',master_port=xxxx,master_user='xxx',master_password='******',MASTER_LOG_FILE='mysql1_bin.000007', MASTER_LOG_POS=426114256 ,master_delay=28800;
stop slave;
CHANGE MASTER TO master_delay=28800;
start slave;

show slave status\G
SQL_Delay: 28800 ---期望的延遲時間
SQL_Remaining_Delay: 28774 ---需要等待多久才能到達期望延遲時間
Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master executed event
===============使用延遲復制恢復主庫誤刪的表
從庫開啟延遲復制
主庫查看刪表的binlog位置
show master status;
show binlog events in 'mysql-bin.000003';
pager grep -iB 5 drop
show binlog events in 'mysql-bin.000003';

從庫恢復到drop之前的位點
stop slave;
CHANGE MASTER TO master_delay=0;
start slave until master_log_file='xxx',master_log_pos=xxx;

show slave status\G ?--確認恢復到指定位置
Master_Log_File=Relay_Master_Log_File
Exec_Master_Log_Pos=Until_Log_Pos
Slave_SQL_Running='No'
導出數據導入到主庫

============================主從延遲============================
===============如何分析主從延遲
1 從庫服務器的負載情況
top?
iostat -xm 1
2 主從復制狀態
show master status;
show slave status\G
對比主位點以及備讀取位點
對比備讀取位點以及備執行位點
3 主庫binlog寫入量
===============主從延遲常見原因以及解決方法
1 IO線程存在延遲
網絡延遲 ?--開啟slave_compressed_protocol,啟用binlog壓縮
磁盤IO存在瓶頸 ?--調整從庫雙1設置或者關閉binlog
網卡問題
2 sql線程存在延遲
a 主庫binlog寫入量過大,SQL線程單線程重放
具體體現:
從庫磁盤IO無明顯瓶頸
relay_master_log_file和exec_master_log_pos不斷變化
binlog生成速度快于5分鐘一個,主庫寫入量過大
解決:升級到5.7以上,開啟并行復制
b statement格式下的慢SQL
具體體現:
relay_master_log_file和exec_master_log_pos一段時間沒變化
解決:設置log_slow_slave_statements,記錄從庫的慢SQL,優化SQL
c 表上無索引且binlog為row格式
具體體現:
relay_master_log_file和exec_master_log_pos一段時間沒變化
表無索引操作時,主庫表只會被掃描一次,而row格式下的從庫,對于每條記錄都會掃描一次
解決
從庫臨時創建一個索引
將參數slave_rows_search_algorithms設置為INDEX_SCAN,HASH_SCAN
d 大事務
拆分成小事務
e 從庫上有查詢
消耗系統資源,有鎖等待
查詢操作阻塞主庫的DDL
f 從庫上有備份
全局讀鎖阻塞SQL線程
g 磁盤IO存在瓶頸
===============如何理解seconds_behind_master
根據計算邏輯
1 seconds_behind_master只計算SQL線程的延遲,不計算IO線程的延遲
網絡原因,磁盤瓶頸,slave_net_timeout設置過大,導致的binlog未及時發送
2 binlog為statement和row計算邏輯不一樣
3 級聯復制無法真正反映延遲

主從延遲的監控
8.0之前使用pt-hearteat
8.0使用如下SQL
select case when min_commit_timestamp is null then 0?
? ? ? ?else unix_timestamp(now(6))-unix_timestamp(min_commit_timestamp) end as seconds_behind_master?
? from (select min(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP) as min_commit_timestamp?
? ? ? ? from performance_schema.replication_applier_status_by_worker?
?? ? ? where applying_transaction<>'') t;