如果要配置审计日志文件名，请设置audit_log_file服务器启动时的系统变量。默认名称为audit.log在服务器数据目录中。为了获得最佳的安全性，请将审计日志写入MySQL服务器和具有合法理由的用户只能访问的目录中。

插件解释audit_log_file值，由可选的主目录名、基目录名和可选的后缀组成。如果启用了压缩或加密，有效文件名(实际用于创建日志文件的名称)与配置的文件名不同，因为它有额外的后缀:

有效的审计日志文件名是在配置的文件名中添加了适用的压缩和加密后缀后产生的名称。例如，如果配置了audit_log_file值是audit.log，有效文件名是下表中显示的值之一。

pwd_id表示加密或解密文件的密码ID。pwd_id格式是pwd_timestamp-seq,地点:

这里有一些例子pwd_id密码ID值:

20190403t142359-1 20190403t142400-1 20190403t142400-2

为了构造相应的密匙环id以在密匙环中存储密码，审计日志插件添加了一个前缀audit_log -到pwd_id值。对于刚刚显示的示例密码id，对应的密匙环id为:

audit_log-20190403T142359-1 audit_log-20190403T142400-1 audit_log-20190403T142400-2

当前审计日志插件用于加密的密码ID为最大的那个pwd_timestamp价值。如果有多个密码pwd_timestamp值，则当前密码ID为序号最大的那个。例如，在前面的密码id集合中，其中两个时间戳最大，20190403 t142400，则当前密码ID为序列号最大的(2)．

审计日志插件在初始化和终止过程中根据有效的审计日志文件名执行某些操作:

如果要配置审计日志文件的格式，需要设置audit_log_format服务器启动时的系统变量。以下格式可供选择:

关于每种格式的详细信息，请参见第6.4.5.4节“审计日志文件格式”．

如果你改变了audit_log_format，建议您也更改audit_log_file．例如，如果你设置audit_log_format来JSON,设置audit_log_file来audit.json．否则，新日志文件的格式将不同于旧文件，但它们都具有相同的基名，没有任何内容表明格式何时更改。

可以为任何日志格式启用审计日志文件压缩。

设置审计日志文件压缩功能时，需要设置audit_log_compression服务器启动时的系统变量。允许的值为没有一个(没有压缩;默认值)和GZIP(GNU Zip压缩)。

如果同时启用压缩和加密，则压缩先于加密。要手动恢复原始文件，首先解密它，然后解压缩它。看到手动解压缩和解密审计日志文件．

可以为任何日志格式启用审计日志文件加密。加密基于用户定义的密码(审计日志插件生成的初始密码除外)。要使用这个特性，必须启用MySQL密匙环，因为审计日志记录使用它来存储密码。任何密匙环组件或插件都可以使用;有关说明，请参见第6.4.4节“MySQL Keyring”．

如果需要配置审计日志文件加密，请设置audit_log_encryption服务器启动时的系统变量。允许的值为没有一个(没有加密;默认值)和AES(AES-256-CBC密码加密)。

要在运行时设置或获取加密密码，请使用以下用户定义函数(udf):

有关审计日志加密udf的更多信息，请参见审计日志功能．

当审计日志插件初始化时，如果它发现日志文件加密已启用，它将检查密匙环是否包含审计日志加密密码。如果没有，插件自动生成一个随机的初始加密密码，并将其存储在密匙环中。要发现此密码，请调用audit_log_encryption_password_get ()．

如果同时启用压缩和加密，则压缩先于加密。要手动恢复原始文件，首先解密它，然后解压缩它。看到手动解压缩和解密审计日志文件．

审计日志文件可以使用标准工具解压和解密。这应该只针对已关闭(存档)且不再使用的日志文件，而不是针对审计日志插件当前正在写入的日志文件。您可以识别归档的日志文件，因为审计日志插件已对它们进行了重命名，以便在文件名中紧跟在基本名称之后包含一个时间戳。

对于本文的讨论，假设audit_log_file设置为audit.log．在这种情况下，归档的审计日志文件具有下表中所示的名称之一。

如在审计日志文件命名约定，pwd_id格式是pwd_timestamp-seq．因此，归档加密日志文件的名称实际上包含两个时间戳。第一个表示文件旋转时间，第二个表示创建加密密码的时间。

考虑以下一组存档加密日志文件名:

audit.20190410T205827.log.20190403T185337-1。内附audit.20190410T210243.log.20190403T185337-1。内附audit.20190415T145309.log.20190414T223342-1。内附audit.20190415t151322.log.20190414t223342 - 2. - enc

每个文件名都有一个惟一的旋转时间戳。相比之下，密码时间戳不是唯一的:

若要手动解压缩已压缩的日志文件，请使用gunzip，gzip - d，或等效命令。例如:

Gunzip -c审计。时间戳.log.gz >审计。时间戳. log

若要手动解密加密的日志文件，请使用openssl命令。例如:

Openssl enc -d -aes-256-cbc -pass pass:密码无-md sha256 -in audit。时间戳. log。pwd_id.enc -out审计。时间戳. log

要执行该命令，您必须获取密码，表示加密密码。要做到这一点，使用audit_log_encryption_password_get ()．例如，审计日志文件名为audit.20190415t151322.log.20190414t223342 - 2. - enc，密码ID为20190414 t223342-2密匙环ID为审计日志- 20190414 t223342 - 2．像这样检索密匙环密码:

选择audit_log_encryption_password_get(“审计日志- 20190414 - t223342 2》);

如果为审计日志同时启用了压缩和加密，则在加密之前进行压缩。在本例中，文件名为. gz而且．pwd_id.enc添加后缀，对应于这些操作发生的顺序。如果需要手动恢复原始文件，请反向操作。也就是说，首先解密文件，然后解压缩它:

Openssl enc -d -aes-256-cbc -pass pass:密码无-md sha256 -in audit。时间戳.log.gz。pwd_id.enc -out审计。时间戳.log.gz gunzip -c审计。时间戳.log.gz >审计。时间戳. log

本节将介绍MySQL 8.0.17之前和MySQL 8.0.17之前审计日志文件加密功能的差异，MySQL 8.0.17是实现密码历史记录的时候(包括密码存档和过期)。它还指示了审计日志插件如何处理从8.0.17以下版本升级到MySQL 8.0.17或更高版本。

在MySQL 8.0.17之前，没有密码历史记录，因此设置新密码将使旧密码不可访问，使MySQL企业审计无法读取用旧密码加密的日志文件。如果您预期需要手动解密这些文件，则必须保留以前密码的记录。

如果从低版本升级到MySQL 8.0.17或更高版本时启用了审计日志文件加密，审计日志插件会执行以下升级操作:

审计日志文件有可能变得相当大，并消耗大量磁盘空间。要管理使用的空间，请使用以下方法:

使用以下系统变量配置审计日志文件空间管理:

以下部分将更详细地描述日志文件的旋转和修剪。

手动审计日志文件旋转

如果audit_log_rotate_on_size为0(默认值)，则除非手动执行，否则不会发生日志旋转。在这种情况下，审计日志插件关闭并重新打开日志文件audit_log_flush从disabled变为enabled。日志文件重命名必须在服务器外部完成。假设日志文件名为audit.log您想要维护三个最近的日志文件，遍历名称audit.log.1通过audit.log.3．在Unix上，像这样手动执行旋转:

自动轮换审计日志文件

如果audit_log_rotate_on_size大于0，设定audit_log_flush没有效果。相反，每当对当前日志文件的写操作导致其大小超过audit_log_rotate_on_size值时，审计日志插件将自动重命名当前日志文件，并使用原来的名称打开一个新的当前日志文件。

自动基于大小的旋转也发生在以下条件下:

该插件通过在原始文件的基名后面插入时间戳来重命名原始文件。例如，如果文件名为audit.log，插件将其重命名为一个值，例如audit.20210115T140633.log．时间戳是格式中的UTC值名称Thhmmss格式。对于XML日志记录，时间戳指示旋转时间。对于JSON日志记录，时间戳是写入文件的最后一个事件的时间戳。

如果对日志文件进行了加密，则原始文件名已经包含一个时间戳，指示加密密码创建时间(参见审计日志文件命名约定)．在本例中，旋转后的文件名包含两个时间戳。例如，一个名为audit.log.20210110t130749 - 1. - enc重命名为诸如audit.20210115t140633.log.20210110t130749 - 1. - enc．

审计日志文件修剪

如果启用了自动旋转日志文件，审计日志插件支持对旋转的json格式审计日志文件进行修剪。要使用此功能:

如果启用了json格式的日志文件，修剪的过程如下:

对于基于组合旋转日志文件大小的修剪，如果组合大小大于指定的限制audit_log_max_size，审计日志插件会删除最旧的文件，直到它们的总大小不超过限制。

对于基于旋转日志文件年龄的剪枝，剪枝点为当前时间减去的值audit_log_prune_seconds．在旋转的json格式日志文件中，每个文件名的时间戳部分表示写入文件的最后一个事件的时间戳。审计日志插件使用文件名时间戳来确定哪些文件只包含比修剪点更早的事件，并删除它们。

审计日志插件可以使用几种日志写入策略中的任何一种。无论采用何种策略，日志记录都是在尽最大努力的基础上进行的，不能保证一致性。

要指定写策略，请设置audit_log_strategy服务器启动时的系统变量。缺省情况下，策略值为异步插件将异步记录到缓冲区，等待缓冲区是否已满。可以告诉插件不要等待(性能)或使用文件系统缓存(SEMISYNCHRONOUS)或强制输出同步()每次写请求后调用(同步)．

对于异步写策略，则audit_log_buffer_size系统变量是以字节为单位的缓冲区大小。在服务器启动时设置此变量以更改缓冲区大小。该插件使用一个缓冲区，它在初始化时分配缓冲区，在终止时删除缓冲区。插件不为非异步写策略分配这个缓冲区。

异步日志策略具有以下特点:

使用异步日志记录，如果在写入文件期间发生问题，或者插件没有完全关闭(例如，在服务器主机意外退出的情况下)，日志文件的完整性可能会受到损害。要降低这种风险，请设置audit_log_strategy使用同步日志记录。

的缺点性能策略是在缓冲区满时丢弃事件。对于负载严重的服务器，审计日志可能缺少事件。