Home 运维技术 MySQL/Redis相关面试题 By FreelyTomorrow Jun 11, 2024 6 min read MySQL/Redis相关面试题 数据库运维(MySQL和Redis)的面试题总结 1. mysql主从复制原理及配置主从大完整步骤 主从复制依靠三个线程来实现 主库:log dump线程,负责给slave从库的I/O线程输出binlog日志数据 从库: I/O线程:负责请求主库的binlog。并将得到的binlog写入自己的中继日志中。 SQL线程:负责读取中继日志,解析为SQL命令并执行。 主从复制流程 从库执行start slave开启主从复制。从库的I/O线程连接主节点,并请求从指定日志的指定位置之后的日志内容。 主结点接收到从节点的I/O请求后,为每个请求的从节点创建一个log dump线程,并通过这个线程将请求的内容传输给从节点;返回的信息中包括数据本身和下一条记录的start position. 从节点的I/O线程接收到binlog日志数据后,将其写入到自己的中继日志的尾端,将binlog文件名和pos值保存到master_info文件中,并依据master_info中的记录提出下一次请求。 从节点的SQL线程在检测到中继日志更新后,会将新日志数据解析为SQL语句并执行,然后在relay_log中记录执行了的中继日志文件名和最新pos值。 2. mysql主从复制故障如何解决 取决于故障类型 主从数据不一致 可能是从库没有设置read_only=1,并且管理员在从库上做了错误的数据增减操作。 解决方法:通过反向操作将数据还原成同步状态,然后重启从库 从库日志丢失 误删除了从库的中继日志,导致还有事务没有同步完成,发生故障 解决方法:查看从库的日志,主要关注relay_master_log_file和exec_master_log_pos的值,这两个值是从库已处理的中继日志文件的位置对应的binlog文件和位置。然后根据这两个值通过CHANGE MASTER TO重新配置主从复制的master log pos. 通用处理方法 - 跳过错误事务 首先确定报错原因 如果确定错误可以忽略,在配置文件中忽略事务 基于binlog: slave-skip-error:error_id 基于GTID:在mysql中set gtid_next=指定的gtid,然后next_gtid为自动 3. mysql主从复制延迟 原因 从库硬件比主库差,导致复制延迟 主从复制单线程,如果主库写并发太大,来不及传送到从库就会导致延迟。更高版本的mysql可以支持多线程复制 慢SQL语句过多 网络延迟 master负载 主库读写压力大,导致复制延迟,架构的前端要加buffer及缓存层 slave负载 解决 读写分离,主库只负责写操作,设从库为只读。 两个优化参数 slave-net-timeout=seconds 单位为秒 默认设置为 3600秒 参数含义:当slave从主数据库读取log数据失败后,等待多久重新建立连接并获取数据 master-connect-retry=seconds 单位为秒 默认设置为 60秒 参数含义:当重新建立主从连接时,如果连接建立失败,间隔多久后重试 slave因为是只读,所以不需要太高的数据安全性,可以将sync_binlog设置为0或者关闭binlog俩提升性能。 提升从库硬件水平 4. Redis内存数据满了,会宕机吗? Redis有六种淘汰策略,用来在内存使用达到上限时淘汰以前的数据来保证新数据的写入,这六种分别是: noeviction(默认策略):若是内存的大小达到域值,写操作会被阻塞,会返回Out Of Memory异常。 allkeys-lru:所有key都是使用LRU算法进行淘汰。 volatile-lru:所有设置了过期时间的key使用LRU算法进行淘汰。 allkeys-random:所有的key使用随机淘汰的方式进行淘汰。 volatile-random:所有设置了过期时间的key使用随机淘汰的方式进行淘汰。 volatile-ttl:所有设置了过期时间的key根据过期时间进行淘汰,越早过期就越快被淘汰。 要在Redis中设置淘汰策略,可以在redis.conf中加入配置 # maxmemory-policy 淘汰策略 maxmemory-policy allkeys-lru 5. MySQL Binlog的三种形式 MySQL的bin log有三种主要的格式:STATEMENT、ROW和MIXED。 STATEMENT 能够记录SQL语句。优点是数据量较小,因为只记录SQL语句本身,对于简单的语句执行较快;缺点是对于一些特定的SQL语句,如非确定性函数(如UUID()、RAND())或使用了NOW()等时间函数的语句,可能导致主从复制中的不一致性。此外,在并行复制时,可能会因为锁的不同步问题,影响复制的性能和准确性。 ROW 能够记录每一行的数据变化,复制非常精确,能够确保主从数据一致性,同时对于复杂的事务和语句,能够避免STATEMENT格式可能出现的不一致问题。 缺点:日志量较大,因为要记录每一行的变化数据,特别是在更新大量数据时。对频繁更新的大表使用,磁盘IO开销会显著增加。 MIXED MIXED是STATEMENT和ROW的混合模式。一般情况下使用STATEMENT格式,但在一些可能导致不一致的操作时会自动切换到ROW格式。 优点:综合了两者的优点,能够在尽量减少日志量的同时,保证数据一致性; 对于大多数场景都能提供较好的性能和准确性。 缺点:复杂性增加,需要更多的系统资源来判断使用哪种格式;仍然会有一定的日志量增加,虽然一般比纯ROW模式小。 Read Next By FreelyTomorrow Aug 16, 2024 使用Terraform在Ubuntu中部署KVM虚拟机 使用Terraform部署KVM虚拟机的详细流程 运维技术 Terraform KVM By FreelyTomorrow May 9, 2024 事件源模式和传统数据库方法在数据管理上的优劣分析 对事件源模式和传统数据库方法在应用程序性能影响、性能、扩展性和可靠性的分析;以及云原生环境下数据管理的最佳实践 云原生 By FreelyTomorrow Apr 24, 2024 关于Metrics_server在自托管环境下无法使用的问题 修复kubernetes的metrics server在自托管环境下因缺少CA证书而无法运行的问题。 Kubernetes By FreelyTomorrow Apr 5, 2024 关于IP、子网掩码、主机位和网络位的计算方法 如何通过子网掩码和掩码位计算一个IP地址的网络地址和可分配的主机位 网络
By FreelyTomorrow Aug 16, 2024 使用Terraform在Ubuntu中部署KVM虚拟机 使用Terraform部署KVM虚拟机的详细流程 运维技术 Terraform KVM
By FreelyTomorrow May 9, 2024 事件源模式和传统数据库方法在数据管理上的优劣分析 对事件源模式和传统数据库方法在应用程序性能影响、性能、扩展性和可靠性的分析;以及云原生环境下数据管理的最佳实践 云原生
By FreelyTomorrow Apr 24, 2024 关于Metrics_server在自托管环境下无法使用的问题 修复kubernetes的metrics server在自托管环境下因缺少CA证书而无法运行的问题。 Kubernetes
1. mysql主从复制原理及配置主从大完整步骤
主从复制依靠三个线程来实现
主库:log dump线程,负责给slave从库的I/O线程输出binlog日志数据
从库:
主从复制流程
2. mysql主从复制故障如何解决
取决于故障类型
主从数据不一致
可能是从库没有设置read_only=1,并且管理员在从库上做了错误的数据增减操作。
解决方法:通过反向操作将数据还原成同步状态,然后重启从库
从库日志丢失
误删除了从库的中继日志,导致还有事务没有同步完成,发生故障
解决方法:查看从库的日志,主要关注relay_master_log_file和exec_master_log_pos的值,这两个值是从库已处理的中继日志文件的位置对应的binlog文件和位置。然后根据这两个值通过CHANGE MASTER TO重新配置主从复制的master log pos.
通用处理方法 - 跳过错误事务
3. mysql主从复制延迟
原因
解决
参数含义:当slave从主数据库读取log数据失败后,等待多久重新建立连接并获取数据
参数含义:当重新建立主从连接时,如果连接建立失败,间隔多久后重试
4. Redis内存数据满了,会宕机吗?
Redis有六种淘汰策略,用来在内存使用达到上限时淘汰以前的数据来保证新数据的写入,这六种分别是:
要在Redis中设置淘汰策略,可以在redis.conf中加入配置
5. MySQL Binlog的三种形式
MySQL的bin log有三种主要的格式:STATEMENT、ROW和MIXED。
STATEMENT
能够记录SQL语句。优点是数据量较小,因为只记录SQL语句本身,对于简单的语句执行较快;缺点是对于一些特定的SQL语句,如非确定性函数(如UUID()、RAND())或使用了NOW()等时间函数的语句,可能导致主从复制中的不一致性。此外,在并行复制时,可能会因为锁的不同步问题,影响复制的性能和准确性。
ROW
能够记录每一行的数据变化,复制非常精确,能够确保主从数据一致性,同时对于复杂的事务和语句,能够避免STATEMENT格式可能出现的不一致问题。
缺点:日志量较大,因为要记录每一行的变化数据,特别是在更新大量数据时。对频繁更新的大表使用,磁盘IO开销会显著增加。
MIXED
MIXED是STATEMENT和ROW的混合模式。一般情况下使用STATEMENT格式,但在一些可能导致不一致的操作时会自动切换到ROW格式。
优点:综合了两者的优点,能够在尽量减少日志量的同时,保证数据一致性; 对于大多数场景都能提供较好的性能和准确性。
缺点:复杂性增加,需要更多的系统资源来判断使用哪种格式;仍然会有一定的日志量增加,虽然一般比纯ROW模式小。
Read Next
使用Terraform在Ubuntu中部署KVM虚拟机
使用Terraform部署KVM虚拟机的详细流程
事件源模式和传统数据库方法在数据管理上的优劣分析
对事件源模式和传统数据库方法在应用程序性能影响、性能、扩展性和可靠性的分析;以及云原生环境下数据管理的最佳实践
关于Metrics_server在自托管环境下无法使用的问题
修复kubernetes的metrics server在自托管环境下因缺少CA证书而无法运行的问题。
关于IP、子网掩码、主机位和网络位的计算方法
如何通过子网掩码和掩码位计算一个IP地址的网络地址和可分配的主机位