查看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;