mysql面试题七（集群）

目录

1.mySQL 中有哪些常见日志

错误日志（Error Log）

二进制日志（Binary Log, Binlog）

重做日志（Redo Log）

回滚日志（Undo Log）

慢查询日志（Slow Query Log）

一般查询日志（General Query Log）

中继日志（Relay Log）

2.mysql主从复制

主从复制原理

主从复制配置步骤

注意事项

3.异步复制和半同步

异步复制（Asynchronous Replication）

半同步复制（Semi-Synchronous Replication）

4.mysql 高可用方案有哪些

---

1.mySQL 中有哪些常见日志

MySQL 中有多种日志，它们各自承担着不同的功能，对于数据库的运行、故障诊断、数据恢复、性能分析和复制等都有着重要作用。以下列举了 MySQL 中常见的几种日志：

1. 错误日志（Error Log）

   • 作用：记录 MySQL 服务器启动、运行过程中的错误信息、警告消息和其他重要事件。它是排查数据库问题的第一手资料，帮助管理员了解服务器运行状态和定位问题。
   • 配置：通过 log_error 参数指定错误日志文件的位置。

2. 二进制日志（Binary Log, Binlog）

   • 作用：记录数据库中所有更改数据的逻辑操作（如 INSERT、UPDATE、DELETE、CREATE TABLE 等），主要用于数据复制（主从复制、多源复制）和数据恢复（基于时间点的恢复、增量备份）。Binlog 是逻辑日志，记录的是 SQL 语句或其等价事件。
   • 配置：通过 log_bin 参数开启二进制日志，binlog_format 参数设置日志格式（STATEMENT、ROW、MIXED），log_bin_basename 参数指定日志文件的基本名，max_binlog_size 设置单个日志文件的最大尺寸。

3. 重做日志（Redo Log）

   • 作用：InnoDB 存储引擎特有的日志，记录对数据页的物理更改操作。重做日志用于崩溃恢复，确保事务的持久性。即使在服务器突然宕机的情况下，也能通过重播重做日志将未写入数据文件的已提交事务的更改恢复出来。
   • 配置：由 InnoDB 自动管理，通常不需要显式配置。可通过 innodb_log_file_size 设置单个日志文件的大小，innodb_log_files_in_group 设置日志文件组中文件的数量，innodb_flush_log_at_trx_commit 控制日志刷新到磁盘的频率。

4. 回滚日志（Undo Log）

   • 作用：InnoDB 存储引擎用于实现事务的原子性和隔离性。回滚日志记录了事务对数据的旧版本，用于在事务回滚时撤销已做的更改，以及在多版本并发控制（MVCC）中为其他事务提供一致性读视图。
   • 配置：由 InnoDB 自动管理，通常不需要显式配置。可通过 innodb_undo_tablespaces、innodb_undo_logs 等参数调整回滚日志的空间管理策略。

5. 慢查询日志（Slow Query Log）

   • 作用：记录执行时间超过指定阈值（由 long_query_time 参数设定）的 SQL 查询语句，以及没有使用到索引的查询。慢查询日志是优化查询性能的重要工具，帮助识别和改进数据库中的低效查询。
   • 配置：通过 slow_query_log 参数开启慢查询日志，slow_query_log_file 参数指定日志文件路径。

6. 一般查询日志（General Query Log）

   • 作用：记录所有对 MySQL 服务器的连接、断开以及每个连接上执行的所有 SQL 语句（包括成功的、失败的和不产生任何表更改的查询）。一般查询日志用于审计和调试，但因其记录量大，通常仅在诊断问题时临时开启。
   • 配置：通过 general_log 参数开启一般查询日志，general_log_file 参数指定日志文件路径。

7. 中继日志（Relay Log）

   • 作用：在主从复制环境中，从服务器接收主服务器的二进制日志事件后，将其写入本地的中继日志中，然后由 SQL 线程从中继日志中读取事件并应用到从服务器的数据库中。中继日志是主从复制过程中的中间传递环节。
   • 配置：在从服务器上自动创建和管理，一般无需显式配置。可通过 relay_log、relay_log_info_file 等参数调整中继日志的相关设置。

以上就是 MySQL 中常见的日志类型及其作用。正确配置和使用这些日志对于监控数据库运行状况、诊断问题、优化性能、实现数据复制以及确保数据一致性至关重要。在实际使用中，应根据需求合理启用和管理相关日志，同时注意日志文件的大小和数量，避免对系统资源造成过大压力。

2.mysql主从复制

MySQL 主从复制（Master-Slave Replication）是一种数据同步技术，通过将主数据库（Master）的数据变更自动复制到一个或多个从数据库（Slave），实现数据的分布式存储、负载均衡、容灾备份和读写分离等功能。以下是 MySQL 主从复制的基本原理、配置步骤和注意事项：

主从复制原理

1. 二进制日志（Binlog）：主库将所有更改数据的 SQL 语句（或等价的事件）记录到二进制日志中。这些日志记录了数据库的逻辑更改操作，是主从复制的基础。

2. 复制线程：

   • IO 线程（Slave IO Thread）：从库启动一个 IO 线程，连接到主库，请求并接收主库的二进制日志事件。
   • SQL 线程（Slave SQL Thread）：从库接收到二进制日志事件后，启动 SQL 线程，将这些事件在从库上按顺序执行，实现数据的同步。

3. 复制过程：

   • 主库：执行客户端提交的事务，将更改记录到二进制日志。
   • 从库：IO 线程读取主库的二进制日志事件并写入本地的中继日志（Relay Log）；SQL 线程从中继日志中读取并执行事件，更新从库数据。
   • 心跳与确认：主从之间通过定期发送心跳包保持连接，从库在接收到事件并执行后向主库发送确认信息。

主从复制配置步骤

1. 主库配置：

   • 开启二进制日志：设置 log_bin 参数启用二进制日志。
   • 设置服务器唯一ID：通过 server-id 参数为每个服务器分配一个唯一的标识符。

2. 从库配置：

   • 设置服务器ID：与主库不同，避免冲突。
   • 指定主库信息：通过 change master to 语句指定主库的主机名/IP、端口、用户名、密码以及要从哪个二进制日志文件和位置开始复制。

3. 启动复制：

   • 从库启动复制：在从库上执行 start slave 命令启动复制线程。
   • 检查复制状态：使用 show slave status 命令检查复制是否正常进行。

注意事项

• 数据一致性：在设置主从复制前，确保主从库的数据一致。通常需要进行全量备份恢复或使用 mysqldump 导出主库数据导入从库。

• 复制延迟：从库的更新通常会滞后于主库，延迟取决于网络延迟、从库的处理能力等因素。对于实时性要求较高的应用，需考虑复制延迟的影响。

• 故障转移与恢复：主库故障时，可将从库提升为主库（手动或自动），但需要注意数据的一致性和同步问题。主库恢复后，可能需要重新配置复制链路或进行数据同步。

• 读写分离：通过主从复制实现读写分离，将读操作导向从库，写操作仍由主库处理，可以减轻主库压力，提高系统整体性能。

• 监控与维护：定期检查复制状态，监控主从延迟，及时处理复制中断、数据不一致等问题。对主从库的性能、磁盘空间、日志文件等进行常规维护。

• 安全：确保主从间复制用户的权限适当，使用安全的连接方式（如 SSL），防止数据在传输过程中被窃取。

总之，MySQL 主从复制通过复制主库的二进制日志到从库并执行，实现了数据的异步复制和分布式存储。正确配置和管理主从复制能够提高系统的可用性、扩展性和数据安全性，是大规模数据库部署和管理中的重要技术手段。

3.异步复制和半同步

MySQL 中的异步复制（Asynchronous Replication）和半同步复制（Semi-Synchronous Replication）是两种不同的数据复制模式，它们决定了主库在处理客户端事务提交后的不同行为以及与从库数据同步的严格程度。

异步复制（Asynchronous Replication）

特点与工作原理：

• 非阻塞：主库在接收到客户端的写请求并完成事务处理后，立即向客户端返回确认（即提交事务），无需等待从库的任何响应。这意味着主库在事务提交后即刻释放资源，继续处理后续请求，无需等待数据复制到从库。
• 延时：由于主库不等待从库确认，数据同步到从库存在一定的延迟，延迟时间取决于网络状况、从库处理速度等因素。
• 风险：在异步复制模式下，如果主库在数据尚未完全复制到从库时发生故障，可能导致从库数据落后于主库，即数据不一致。在故障切换时，未复制到从库的事务可能丢失。

适用场景：

• 对数据一致性要求相对较低，允许一定时间窗口内的数据延迟。
• 对主库性能敏感，追求最大化写入吞吐量。
• 可接受在主库故障时可能存在的少量数据损失风险。

半同步复制（Semi-Synchronous Replication）

特点与工作原理：

• 部分阻塞：主库在接收到客户端的写请求并完成事务处理后，不立即返回确认给客户端，而是等待至少一个从库（或满足特定条件的从库集合）接收并写入其中继日志（Relay Log）后，才向客户端返回确认。
• 确认机制：主库上的半同步插件会在事务提交后等待从库的确认信号（Acknowledge），确保至少有一个从库已接收事务数据，降低了数据丢失的风险。
• 延迟与性能折衷：相较于异步复制，半同步复制增加了对从库响应的等待时间，可能导致主库写入性能下降，但显著提高了数据一致性。在大多数情况下，这个等待时间是短暂的，不会对系统整体性能造成显著影响。
• 故障处理：如果从库未能及时响应，半同步复制可以配置超时策略，超过指定时间后降级为异步复制，以避免主库长时间阻塞。这种机制在一定程度上兼顾了数据安全性和系统可用性。

适用场景：

• 对数据一致性要求较高，无法接受长时间的数据延迟。
• 能够接受一定程度的写入性能降低以换取更高的数据安全性。
• 需要在主库故障时最大限度地减少数据丢失的可能性。

总结来说，异步复制和半同步复制的主要区别在于主库在提交事务时对从库响应的依赖程度：

• 异步复制以牺牲数据一致性为代价，换取更高的写入性能和更低的主库延迟，适用于对数据延迟容忍度较高、追求高性能写入的应用场景。
• 半同步复制在保证较高数据一致性和降低数据丢失风险的同时，适度牺牲写入性能，适用于对数据安全性有较高要求、能够接受适度性能损失的业务环境。

4.mysql 高可用方案有哪些

MySQL高可用九种方案_mysql 高可用方案-CSDN博客