mysql【週五】day18

主從延時問題的監控以及處理建議
監控方法：
方法一：確定有沒有延時
Seconds_Behind_Master: 0（秒數）

方法二：
主庫：

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

從庫：

[root@db01 data]# mysql -S /tmp/mysql3308.sock -uroot -p123  -e "show slave status \G"|grep "Master_Log"

已經拿到的主庫日誌量(master.info)：判斷傳輸有沒有延時

Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 151847

已經執行的主庫日誌量(relay-log.info): 判斷回放有沒有延時

Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 141847

計算主從複製延時日誌量。

導致延時的主要原因

外部因素
網絡延時
主從硬件、參數等不一致
從庫太多
主庫壓力太大

主庫：

（1） binlog記錄不及時。

mysql> select @@sync_binlog;
+---------------+
| @@sync_binlog |
+---------------+
|             1 |
+---------------+

參數說明：
1 ：每次事務提交都立即刷新binlog到磁盤。
0 ：由操作系統決定，什麼刷新磁盤。

（2） DUMP線程串行工作。
大事務、併發事務高、DDL
解決辦法：
5.6版本加入GTID複製模式，但手工配置。DUMP在傳輸日誌時可以併發。
5.7版本GTID做了增強，不手工開啓也自動維護匿名的GTID信息。

（3）怎麼判斷是主庫導致的延時？
主庫：

mysql> show master status ;

從庫：

mysql -S /tmp/mysql3308.sock -uroot -p123  -e "show slave status \G"|grep "Master_Log"

從庫方面
#IO線程：
從庫IO比較慢。relay 落地慢。可以將realy放到 SSD

#SQL 線程：串行回放。
主庫可以並行事務，從庫SQL線程串行回放。
所以：併發事務高、大事務、DDL

解決方法：
5.6 版本：開啓GTID後，可以多SQL線程，只能針對不同的庫的事務進行並行SQL恢復。
5.7 版本：做了增強，基於邏輯時鐘的並行回放。MTS。

5.7 的從庫併發配置方法。

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE

#已經執行的主庫日質量(relay-log.info): 判斷回放有沒有延時

Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 141847

過濾複製
7.1 主庫實現
binlog_do_db 白名單
binlog_ignore_db 黑名單

說明：是否記錄binlog日誌來控制過濾。

7.2 從庫實現 ******
實現方法：
IO線程不做限制。
SQL線程回放時，選擇性回放。

參數：

replicate_do_db=world
replicate_do_db=oldboy
replicate_ignore_db= 

replicate_do_table=world.city 
replicate_ignore_table= 

replicate_wild_do_table=world.t*
replicate_wild_ignore_table=

配置方法：
方法一：
修改配置文件並重啓

vim /data/3308/my.cnf 
replicate_do_db=world
replicate_do_db=oldboy
systemctl restart mysqld3308

方法二：

STOP SLAVE SQL_THREAD;
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (oldguo, oldboy);
START  SLAVE SQL_THREAD;

延時從庫的應用
配置方法：

mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql>start slave;
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL

思路：
主庫發生了邏輯損壞（DROP，truncate）時，可以使用延時從庫快速恢復數據。

2小時延時  
10：00  做的drop database A;

及時監控故障：主庫 10:05發現故障，從庫此時8:05數據狀態
立即將從庫的SQL線程關閉。需要對A業務掛維護頁。
停止所有線程。
在延時從。恢復A庫數據
手工模擬SQL線程工作，直到drop之前位置點。
SQL線程上次執行到的位置------》drop之前
relay.info ----> 分析drop位置點 —》截取relaylog日誌----》 source

故障模擬及恢復
故障模擬：

create database delaydb charset utf8mb4;
use delaydb;
create table t1(id int);
insert into t1 values(1),(2),(3);
commit;

drop database delaydb;

截取日誌：

起點: SQL上次執行到的位置點，

Relay_Log_File: db01-relay-bin.000004
Relay_Log_Pos: 320

終點： drop 之前

db01-relay-bin.000004 | 1006 | Query          |         7 |      152967 | drop databas

[root@db01 tmp]# mysqlbinlog --start-position=320 --stop-position=1006 /data/3309/data/db01-relay-bin.000004 >/tmp/bin.sql

mysql> reset slave all;
mysql> set sql_log_bin=0;
mysql> source /tmp/bin.sql;
mysql> set sql_log_bin=1;


mysql> show  tables;
+-------------------+
| Tables_in_delaydb |
+-------------------+
| t1                |
+-------------------+
1 row in set (0.00 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+

GTID複製
清理環境

pkill mysqld
 \rm -rf /data/mysql/data/*
 \rm -rf /data/binlog/*
mkdir -p /data/mysql/data /data/binlog 


chown -R mysql.mysql /data/*

準備配置文件
主庫db01：

mv /etc/my.cnf /tmp
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/data/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOF

slave1(db02)：

mv /etc/my.cnf /tmp
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/data/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOF

slave2(db03)：

mv /etc/my.cnf /tmp
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/data/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF

初始化數據

mysqld --initialize-insecure --user=mysql --basedir=/data/app/mysql  --datadir=/data/mysql/data

啓動數據庫

/etc/init.d/mysqld start

9.5 構建主從：
master:51
slave:52,53

51:

grant replication slave  on *.* to repl@'10.0.0.%' identified by '123';

52\53:

change master to 
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;

start slave;

mysql【週五】day18

druid數據源 xml配置

mysql【週一】day19

mysql【週五】day18

mysql【週二】day20

mysql【週四】day17

mysql【週三】day16

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結