运维技术 MySQL Redis

MySQL/Redis相关面试题

数据库运维(MySQL和Redis)的面试题总结
FreelyTomorrow
FreelyTomorrow
6 min read
MySQL/Redis相关面试题
Photo by Jandira Sonnendeck / Unsplash

1. mysql主从复制原理及配置主从大完整步骤

主从复制依靠三个线程来实现

主库：log dump线程，负责给slave从库的I/O线程输出binlog日志数据
从库：

  • I/O线程：负责请求主库的binlog。并将得到的binlog写入自己的中继日志中。
  • SQL线程：负责读取中继日志，解析为SQL命令并执行。

主从复制流程

  1. 从库执行start slave开启主从复制。从库的I/O线程连接主节点，并请求从指定日志的指定位置之后的日志内容。
  2. 主结点接收到从节点的I/O请求后，为每个请求的从节点创建一个log dump线程，并通过这个线程将请求的内容传输给从节点；返回的信息中包括数据本身和下一条记录的start position.
  3. 从节点的I/O线程接收到binlog日志数据后，将其写入到自己的中继日志的尾端，将binlog文件名和pos值保存到master_info文件中，并依据master_info中的记录提出下一次请求。
  4. 从节点的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.

通用处理方法 - 跳过错误事务

  1. 首先确定报错原因
  2. 如果确定错误可以忽略，在配置文件中忽略事务
    • 基于binlog: slave-skip-error:error_id
    • 基于GTID：在mysql中set gtid_next=指定的gtid，然后next_gtid为自动

3. mysql主从复制延迟

原因

  1. 从库硬件比主库差，导致复制延迟
  2. 主从复制单线程，如果主库写并发太大，来不及传送到从库就会导致延迟。更高版本的mysql可以支持多线程复制
  3. 慢SQL语句过多
  4. 网络延迟
  5. master负载 主库读写压力大，导致复制延迟，架构的前端要加buffer及缓存层
  6. slave负载

解决

  1. 读写分离，主库只负责写操作，设从库为只读。
  2. 两个优化参数
    • slave-net-timeout=seconds 单位为秒 默认设置为 3600秒
      参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据
    • master-connect-retry=seconds 单位为秒 默认设置为 60秒
      参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试
  3. slave因为是只读，所以不需要太高的数据安全性，可以将sync_binlog设置为0或者关闭binlog俩提升性能。
  4. 提升从库硬件水平

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模式小。

You might also like