Skip to main content

1.MySQL面试题

备份mysql test库​

mysql -uroot -pxxxxx -B test > /mysql_backup/test.sql
  • -B选项启用了批处理模式，使得结果以无格式的方式输出，

mysql主从原理​

主从复制的基本流程：​

  1. 主服务器（Master）：
    • 主服务器是数据库的主要来源，负责处理写操作（INSERT、UPDATE、DELETE）以及事务提交。
    • 在主服务器上，MySQL将所有的写操作记录到二进制日志（Binary Log）中。
  2. 从服务器（Slave）：
    • 从服务器是主服务器的副本，用于处理读操作和提供冗余。
    • 从服务器通过连接到主服务器并请求复制日志来获取主服务器的更新。
  3. 复制日志传输：
    • 主服务器将写操作的信息以二进制日志的形式保存，从服务器通过网络连接获取这些二进制日志文件。
    • 从服务器通过 CHANGE MASTER TO命令指定主服务器的位置，从而开始获取二进制日志。
  4. 应用复制日志：
    • 从服务器将接收到的二进制日志应用到自己的数据库，从而与主服务器保持同步。
    • 从服务器在本地执行主服务器上执行的相同写操作，确保数据一致性。

配置步骤：​

  1. 在主服务器上启用二进制日志：
    • 在主服务器的配置文件中启用二进制日志，通常通过设置 log_bin参数。
  2. 创建用于复制的用户：
    • 在主服务器上创建一个用于从服务器连接的MySQL用户，该用户需要具有复制权限。
  3. 在从服务器上配置复制：
    • 在从服务器上通过 CHANGE MASTER TO命令配置主服务器的位置和连接信息，包括主服务器的IP地址、端口、复制用户和密码等。
  4. 启动从服务器的复制：
    • 在从服务器上执行 START SLAVE命令，使从服务器开始获取并应用主服务器的二进制日志。

mysql主从复制延迟原因​

  1. 网络延迟：
    • 原因： 主从服务器之间的网络延迟可能导致数据同步的延迟。
    • 解决方法： 优化网络连接，确保网络带宽足够，并检查网络是否存在问题。
  2. 主从服务器性能不平衡：
    • 原因： 主从服务器的性能不平衡可能导致从服务器无法及时处理来自主服务器的复制事件。
    • 解决方法： 提高从服务器的硬件性能，例如增加内存、CPU，或者调整 MySQL 配置参数以优化性能。
  3. 大事务或高写入负载：
    • 原因： 当主服务器上有大事务或高写入负载时，从服务器可能会因为复制这些事务而延迟。
    • 解决方法： 拆分大事务，优化 SQL 查询，或者考虑使用从服务器复制过滤功能排除不必要的表或语句。
  4. 从服务器配置不当：
    • 原因： 从服务器的配置参数不当可能导致性能瓶颈。
    • 解决方法： 确保从服务器的 MySQL 配置参数适当调整，以适应实际需求。特别关注 innodb_buffer_pool_size、innodb_log_file_size 等参数。
  5. 主从服务器时间不同步：
    • 原因： 主从服务器的系统时间不同步可能导致复制延迟。
    • 解决方法： 使用 NTP（Network Time Protocol）确保主从服务器的系统时间同步。
  6. 从服务器资源竞争：
    • 原因： 如果从服务器上同时运行其他资源密集型任务，可能影响复制性能。
    • 解决方法： 确保从服务器上不同时运行其他占用大量资源的任务，或者考虑使用专用的从服务器。
  7. MySQL版本不同：
    • 原因： 如果主从服务器使用不同版本的 MySQL，可能会导致复制延迟。
    • 解决方法： 确保主从服务器使用相同版本的 MySQL，并且升级到最新的稳定版本。

在解决延迟问题时，建议使用工具监控 MySQL 复制的状态，例如通过查看 SHOW SLAVE STATUS; 命令的输出，以获取更详细的信息。

mysql主从复制故障原因​

  1. 检查主从服务器的状态：
    • 在主服务器上执行 SHOW MASTER STATUS;，在从服务器上执行 SHOW SLAVE STATUS;，以查看复制状态信息。检查是否有错误消息，以及延迟情况。
  2. 检查网络连接：
    • 确保主从服务器之间的网络连接正常。尝试通过telnet等工具测试网络连接是否通畅。
  3. 检查防火墙设置：
    • 防火墙设置可能导致主从服务器之间的通信问题。确保防火墙允许 MySQL 端口的通信。
  4. 检查权限：
    • 确保主从服务器的 MySQL 用户具有适当的权限。主服务器上的主用户需要有 REPLICATION SLAVE 权限，而从服务器上的从用户需要有 REPLICATION CLIENT 和 REPLICATION SLAVE 权限。
  5. 检查二进制日志文件和位置：
    • 检查主服务器上的二进制日志文件名和位置（File和Position），确保从服务器上的 CHANGE MASTER TO 语句中设置的值正确。
  6. 检查从服务器复制过滤：
    • 如果在从服务器上使用了复制过滤，确保过滤规则没有影响到正常的复制流程。
  7. 检查日志文件和错误日志：
    • 查看主从服务器的 MySQL 错误日志，以获取更多关于故障的详细信息。常见的日志文件路径为 /var/log/mysql/error.log 或 /var/log/mysqld.log。
  8. 重新初始化从服务器：
    • 如果主从服务器之间的差异较大，可以考虑重新初始化从服务器。使用 RESET SLAVE; 命令清除从服务器的复制信息，然后重新配置从服务器。
  9. 检查主从服务器版本：
    • 确保主从服务器使用相同版本的 MySQL，并且都是支持的版本。不同版本之间可能存在兼容性问题。
  10. 检查硬件资源：
    • 确保主从服务器的硬件资源（CPU、内存、磁盘等）足够，不会因为资源不足而导致复制故障。
  11. 使用工具进行故障排除：
    • 使用 MySQL 提供的工具，例如 mysqlbinlog 来查看二进制日志文件，或者 mysqldump 来检查数据是否正确同步。

mysql+keepalived正确的启动顺序是什么？​

  1. 在 MySQL 主节点上，首先启动 MySQL 服务。
  2. 在 MySQL 主节点上，启动 Keepalived 服务。Keepalived 将检测 MySQL 的运行状态并配置 VIP（虚拟 IP）。
  3. 在其他 MySQL 从节点上，启动 MySQL 服务。
  4. 在其他 MySQL 从节点上，启动 Keepalived 服务。

如何排查mysql死锁​

  1. 查看错误日志：
    • MySQL 的错误日志通常位于 /var/log/mysql/error.log 或 /var/log/mysqld.log。查看日志文件以了解是否有死锁的相关信息。
  2. 使用 SHOW ENGINE INNODB STATUS：
    • 在 MySQL 命令行中运行 SHOW ENGINE INNODB STATUS，然后查找输出中关于死锁的信息。
  3. 查看 information_schema 表：
    • 查询 information_schema.INNODB_LOCKS 和 information_schema.INNODB_LOCK_WAITS 表，以获取关于当前锁和等待锁的信息。
  4. 使用 mysqladmin 工具：

    • 使用 mysqladmin 工具检查死锁状态。

      mysqladmin -u<username> -p<password> extended-status | grep -i "Innodb_deadlocks"

mysql备份方案有哪些？​

  1. 物理备份（Physical Backup）：
    • 使用工具如 mysqlbackup 或者 MySQL Enterprise Backup 进行物理备份，备份整个数据库或者指定表的二进制数据文件。
  2. 逻辑备份（Logical Backup）：
    • 使用 mysqldump 工具进行逻辑备份，生成 SQL 脚本，以便恢复数据库结构和数据。
  3. 点播备份（Point-in-Time Recovery）：
    • 使用二进制日志（Binary Log）实现点播备份，使数据库能够还原到某个特定的时间点。
  4. 增量备份：
    • 利用增量备份策略，仅备份发生变化的数据，以减少备份的时间和空间。
  5. 使用第三方备份工具：
    • 使用专业的数据库备份工具，如 Percona XtraBackup、MySQL Enterprise Backup 等，它们提供高性能和更丰富的备份选项。

客户反应某应用接口有时无法调用，请简述排查思路，环境如下：tomcat3,mysql2,mongodb3,redis1,f5*1。​

1.首先如果可以的话，让客户提供报错信息或报错截图，提供复现步骤。

2接口有时无法调用，说明服务并非完全critical状态，可能是性能不足导致，或是服务重启导致。

3.可以从流量路径入手排查：f5 > redis > tomcat > mysql | mogodb

以下提供以下参考排查操作：

  1. 查看应用日志：

    • 首先检查应用的日志文件，查看是否有相关错误或异常信息。这可以提供一些关键的线索，帮助定位问题。

  2. Tomcat 状态检查：

    • 检查每个 Tomcat 实例的状态，确保它们都在运行中。可以使用以下命令查看 Tomcat 进程：

      ps aux | grep tomcat		#确保 Tomcat 的日志文件中没有出现异常或错误信息。

  3. 数据库状态检查：

    • 检查 MySQL 和 MongoDB 的状态，确保它们正常运行。查看数据库的日志文件以获取可能的错误信息。

  4. Redis 状态检查：

    • 确保 Redis 服务正常运行。使用以下命令检查 Redis 服务：

      redis-cli ping		#期望输出为 PONG，表示 Redis 服务正常。

  5. F5 负载均衡器状态检查：

    • 检查 F5 负载均衡器的状态，确保它没有故障或异常。查看 F5 的日志以获取可能的错误信息。

  6. 网络连接检查：

    • 检查网络连接，确保各个组件之间的通信正常。使用 ping 或者其他网络诊断工具检查网络连通性。

  7. 性能监控：

    • 使用监控工具监测各个组件的性能，查看是否存在性能瓶颈。例如，可以使用 top 或者其他监控工具检查系统资源使用情况。

  8. 应用接口调用测试：

    • 使用工具或手动方式对应用接口进行调用测试，观察是否能够重现问题。如果能够重现问题，查看应用日志和错误信息。

  9. 日志分析和排查：

    • 分析以上步骤中收集到的日志和信息，查找潜在的问题。注意是否有定期发生或者特定条件下发生的模式。

  10. 负载均衡配置检查：

    • 检查 F5 负载均衡器的配置，确保请求被正确路由到各个 Tomcat 实例。

  11. 持续监控：

    • 部署持续监控系统，定期检查应用和基础设施的状态。这有助于发现潜在问题并采取预防措施。