AI摘要

本文总结了数据库相关的面试题，主要涉及MySQL、Redis和MongoDB三类数据库。对于MySQL，文章讨论了主从复制原理、一致性问题及其解决方案，以及备份策略。对于Redis，文章介绍了持久化机制。对于MongoDB，文章简要介绍了其主要作用。整体而言，文章为数据库面试提供了全面的知识点。

此内容根据文章生成，仅用于文章内容的解释与总结

主要分为以下三类

一、Mysql

1.mysql主从原理

MySQL 的主从复制是基于主库的二进制日志（binlog）实现的。当主库有数据修改操作（增、删、改）时，这些操作会被记录在 binlog 中。备库通过 I/O 线程从主库拉取 binlog 写入本地中继日志（relay log），然后 SQL 线程读取中继日志并在备库回放这些操作，从而实现数据同步。简单来说，主库写日志，备库读日志并执行，最终保证主备数据一致。

2.mysql主从复制一致性问题

在生产环境中，MySQL 主从架构常用于实现读写分离和数据备份。然而，主从复制过程中可能出现数据不一致的情况，导致从库数据与主库不同步，影响业务正常运行。

1. 主从复制数据不一致的常见原因有哪些？
2. 如何检测主从复制数据不一致？
3. 针对上述问题，您会采取哪些措施来解决或预防数据不一致？

4. 常见原因：

   • 复制链路中断： 主库与从库之间的网络问题、权限配置错误或 binlog 被删除，导致从库无法获取最新的 binlog。
   • 复制延迟： 主库负载过高或从库性能不足，导致从库处理 binlog 的速度跟不上主库的更新速度。
   • SQL 线程报错： 从库在执行 binlog 中的 SQL 语句时发生错误，如主键冲突、数据类型不兼容等。
   • 人为操作： 开发人员或运维人员直接在从库上进行写操作，导致数据与主库不一致。
   • 自增主键冲突： 主从库的 auto\_increment 配置不一致，导致插入数据时主键重复。

5. 检测方法：

   • SHOW SLAVE STATUS： 检查 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes，Seconds_Behind_Master 是否为 0。
   • pt-table-checksum： 使用 Percona Toolkit 的该工具对比主从库中表的哈希值，快速定位数据差异。
   • pt-table-sync： 在发现数据不一致时，使用该工具同步主从库的数据。

6. 解决与预防措施：

   • 启用半同步复制： 配置 rpl_semi_sync_master_enabled 和 rpl_semi_sync_slave_enabled，确保主库提交事务前，至少一个从库确认收到 binlog。
   • 优化主从性能： 调整主库和从库的配置，提升性能，减少延迟。
   • 定期监控： 使用监控工具（如 Prometheus + Grafana）定期检查主从复制状态，设置告警。
   • 禁止直接写入从库： 配置从库为只读，防止直接写入操作。
   • 统一配置： 确保主从库的 MySQL 版本、字符集、排序规则等配置一致。

7. 事发解决

   • 如果是少量数据：可手动进行修改
   • 针对整张表或大量数据：可使用工具 pt-table-sync 自动同步，对于严重不一致的可以从主库导出sql进行从库覆盖。
   • 修改后重新开启主从复制：STOP SLAVE; START SLAVE;

3.mysql备份策略

完整企业级备份策略设计

• 全量 + 增量 / binlog：每日全量 + 每隔几分钟增量
• 热备份：保证备份期间业务可用
• 异地存储：防止单机故障，因服务器都是使用的exsi虚拟化，所以选择异地存储NAS。
• 定期恢复：确保备份可用,每日恢复到测试环境,通过select count验证备份是否可用

二、Redis

1.redis持久化

一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，可以同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
如果非常关心数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。

三、Mongodb