mysql学习

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