跟踪和跟踪活动

  • 11 分钟

维护数据库的大部分内容是性能优化。 Azure Database for MySQL/PostgreSQL 仍可使用用于查看本地数据库的相同日志文件。

将数据库迁移到 Azure 后，需要继续查看日志文件，以确保维护数据库的性能。

在本单元中，你将看到 PostgreSQL 和 MySQL 的日志文件存储在 Azure 中，以及它们包含的详细信息级别。

使用服务器日志跟踪数据库活动

Azure Database for MySQL/PostgreSQL 还会在服务器日志中记录诊断信息。 服务器日志是 MySQL 和 PostgreSQL 的本机消息日志文件（而不是 Azure Database for MySQL/PostgreSQL 中无法访问的事务日志文件）。 这些文件包含用于调试数据库问题的消息、服务器状态和其他错误信息。 服务器日志最多保留七天（如果服务器日志文件的总大小超过 7 GB），则更少。

Azure Database for MySQL 和 Azure Database for PostgreSQL 记录服务器日志中的不同详细信息。 以下各节分别介绍每个服务的服务器日志。

Azure Database for MySQL 中的服务器日志

在 Azure Database for MySQL 中，服务器日志提供 慢查询日志 和 MySQL 服务器上的 审核日志 中通常提供的信息。

使用慢查询日志中的信息来帮助识别运行缓慢的查询。 慢查询日志默认禁用。 通过将 slow_query_log 服务器参数设置为 on 来启用它。 将慢查询日志配置为使用以下服务器参数确定 慢查询 的含义：

  • log_queries_not_using_indexes。 此参数 ON 或 OFF。 将其设置为 ON，以记录可能执行完整表扫描而不是索引查找的所有查询。
  • log_throttle_queries_not_using_indexes。 指定不使用每分钟可记录的索引的最大慢速查询数。
  • log_slow_admin_queries。 将此参数设置为 ON，以在日志中包含运行缓慢的管理查询。
  • long_query_time。 查询的阈值（以秒为单位）被视为 运行速度缓慢。

启用慢查询日志和审核日志后，日志文件将开始显示在服务器的 服务器日志 页中。 每天创建新的慢查询日志。 单击日志文件以下载它：

Azure Database for MySQL 的服务器日志页的图像。

若要启用审核日志记录，请将 audit_log_enabled 服务器参数设置为 ON。 使用以下参数配置审核日志记录：

  • audit_log_events。 指定要审核的事件。 在 Azure 门户中，此参数提供事件下拉列表，例如 CONNECTION、DDL、DML、ADMIN等。
  • audit_log_exclude_users。 此参数是一个逗号分隔的用户列表，其活动不会包含在审核日志中。

如果需要将慢查询日志和审核日志保留 7 天以上，请安排它们传输到 Azure 存储。 使用服务器的 诊断设置 页，然后选择 + 添加诊断设置。 在 诊断设置 页上，选择 存档到存储帐户，选择保存日志文件的存储帐户（此存储帐户必须已存在），选择 MySqlSlowLogs，MySqlAuditLogs，并指定最长 365 天的保留期。 在此期间，可以随时从 Azure 存储下载日志文件。 选择“保存”：

Azure Database for MySQL 的“诊断设置”页的图像。

慢查询日志数据将以 JSON 格式写入 insights-logs-mysqlslowlogs的容器中的 blob。 日志文件最多可能需要 10 分钟才能显示在 Azure 存储中。 审核记录以 JSON 格式再次存储在 insights-logs-mysqlslowlogs blob 容器中。

Azure Database for PostgreSQL 中的服务器日志

在 Azure Database for PostgreSQL 中，服务器日志包含错误日志和查询日志文件。 使用这些文件中的信息来帮助查找任何错误和低效查询的来源。

通过将各种 log_ 服务器配置参数设置为 ON来启用日志记录。 这些参数包括：

  • log_checkpoints。 每当每个数据文件都使用事务日志中的最新信息进行更新时，都会发生检查点。 如果出现服务器故障，则这一点将标志着恢复需要从事务日志向前滚动开始的时间。
  • log_connection 和 log_disconnections。 这些设置记录每个成功的连接，以及每个会话的结束。
  • log_duration。 此设置会导致记录每个已完成的 SQL 语句的持续时间。
  • log_lock_waits。 此设置会导致记录锁定等待事件。 锁等待可能是应用程序代码中实现不当的事务造成的。
  • log_statement_stats。 此设置将有关服务器性能的累积信息写入日志。

Azure Database for PostgreSQL 还提供进一步的参数来微调记录的信息：

  • log_error_verbosity。 此设置指定为每个记录的消息记录的详细信息级别。
  • log_retention_days. 这是服务器在删除日志文件之前保留每个日志文件的天数。 默认值为三天，可将其设置为最多七天。
  • log_min_messages 和 log_min_error_statement。 使用这些参数指定记录语句的警告和错误级别。

与 Azure Database for MySQL 一样，Azure Database for PostgreSQL 生成的日志文件在 服务器日志 页上提供。 还可以使用 诊断设置 页将日志复制到 Azure 存储。

跟踪查询性能

查询存储是 Azure 提供的一项附加功能，可帮助你识别和跟踪运行不佳的查询。 将其与 Azure Database for MySQL 和 Azure Database for PostgreSQL 配合使用。

启用查询性能跟踪

查询将记录信息存储在 Azure Database for MySQL 的 mysql 架构中，以及 Azure Database for PostgreSQL 中名为 azure_sys 的数据库。 查询存储可以捕获两种类型的信息-有关查询执行的数据，以及有关等待统计信息的信息。 默认情况下禁用查询存储。 若要启用：

  • 如果使用 Azure Database for MySQL，请将服务器参数 query_store_capture_mode，并将 query_store_wait_sampling_capture_mode 设置为 ALL。
  • 如果使用 Azure Database for PostgreSQL，请将服务器参数 pg_qs.query_capture_mode 设置为 ALL 或 TOP，并将 pgms_wait_sampling.query_capture_mode 参数设置为 ALL。

分析查询性能数据

可以直接查询查询存储使用的表。 如果运行的是 Azure Database for MySQL，请连接到服务器，并运行以下查询：

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

如果使用 Azure Database for PostgreSQL，请改为运行以下查询：

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

在这两种情况下，第一个查询将显示每个最近运行的查询的文本，以及有关查询编译和执行所花费的时间的统计信息的主机。 第二个查询显示有关等待事件的信息。 当阻止一个查询运行时，会发生等待事件，因为它需要另一个查询持有的资源。

如果直接检查查询存储，可以生成自己的自定义报表，并深入了解系统运行方式。 但是，可用的数据量可能会使理解正在发生的事情变得困难。 Azure Database for MySQL/PostgreSQL 提供了另外两种工具来帮助导航此数据：Query Performance Insight，以及 查询建议。

Query Performance Insight 是一个图形实用工具，可从服务器的 Query Performance Insight 页获取。 长时间运行的查询 选项卡显示运行时间最长的查询的统计信息。 指定时间段，并在几分钟内放大。 图例显示每个查询的文本，以及运行查询的持续时间和次数。 该图提供了每个查询持续时间的比较视图。 按每个查询的平均时间查看数据，但还指示显示每个查询的总时间（持续时间 * 执行计数）。 下图显示了一个示例：

Azure Database for PostgreSQL 的“查询性能见解”页的图像，其中显示了“长时间运行的查询”选项卡。

等待统计信息 选项卡显示每个查询的等待事件信息。 你将看到等待各种资源的查询花费的时间。

Azure Database for PostgreSQL 的“查询性能见解”页的图像，其中显示了“等待统计信息”选项卡。

等待事件通常分为三类：

  • 锁定等待。 如果查询尝试读取或修改被另一个查询锁定的数据，则会发生这些事件。 如果遇到大量锁等待，请检查长时间运行的事务或使用高度限制隔离级别的作。
  • IO 等待。 如果查询执行大量 IO，则会发生这种类型的等待。 这可能是由于设计不佳的查询（检查 WHERE 子句）、低效联接作或由于缺少索引而导致的完整表扫描。
  • 内存等待。 如果内存不足，无法处理查询，则会发生内存等待。 查询可能会尝试读取大量数据，或者其他查询可能会阻止它占用内存。 同样，这可能表示缺少索引，导致查询将整个表读取到内存中。

同样，一种等待形式也很可能触发另一种等待形式，因此你不一定隔离地检查这些问题。 例如，读取和更新不同表中数据的事务可能受到内存等待的约束。 反过来，此事务可能会锁定数据，导致另一个事务产生锁定等待。

服务器的“性能建议” 页采用查询存储中保存的信息，并使用它针对所遇到的工作负荷优化数据库提出建议。