## Write Strategies for Audit Logging 

The audit log plugin can use any of several strategies for log writes. Regardless of strategy, logging occurs on a best-effort basis, with no guarantee of consistency. 

To specify a write strategy, set the audit_log_strategy  system variable at server startup. By default, the strategy value is ASYNCHRONOUS  and the plugin logs asynchronously to a buffer, waiting if the buffer is full. It’s possible to tell the plugin not to wait ( PERFORMANCE ) or to log synchronously, either using file system caching ( SEMISYNCHRONOUS ) or forcing output with a sync()  call after each write request ( SYNCHRONOUS ). 

For asynchronous write strategy, the audit_log_buffer_size  system variable is the buffer size in bytes. Set this variable at server startup to change the buffer size. The plugin uses a single buffer, which it allocates when it initializes and removes when it terminates. The plugin does not allocate this buffer for nonasynchronous write strategies. 

Asynchronous logging strategy has these characteristics: 

•Minimal impact on server performance and scalability. 

•Blocking of threads that generate audit events for the shortest possible time; that is, time to allocate the buffer plus time to copy the event to the buffer. 

•Output goes to the buffer. A separate thread handles writes from the buffer to the log file. 

With asynchronous logging, the integrity of the log file may be compromised if a problem occurs during a write to the file or if the plugin does not shut down cleanly (for example, in the event that the server host exits unexpectedly). To reduce this risk, set audit_log_strategy  to use synchronous logging. 

A disadvantage of PERFORMANCE  strategy is that it drops events when the buffer is full. For a heavily loaded server, the audit log may have events missing. 

## 6.4.5.6 Reading Audit Log Files 

The audit log plugin supports functions that provide an SQL interface for reading JSON-format audit log files. (This capability does not apply to log files written in other formats.) 

When the audit log plugin initializes and is configured for JSON logging, it uses the directory containing the current audit log file as the location to search for readable audit log files. The plugin determines the file location, base name, and suffix from the value of the audit_log_file  system variable, then looks for files with names that match the following pattern, where [...]  indicates optional file name parts: 

basename [. timestamp ]. suffix [.gz][[. pwd_id ].enc] 

If a file name ends with .enc , the file is encrypted and reading its unencrypted contents requires a decryption password obtained from the keyring. The audit log plugin determines the keyring ID of the decryption password as follows: 

•If .enc  is preceded by pwd_id , the keyring ID is audit_log- pwd_id . 

•If .enc  is not preceded by pwd_id , the file has an old name from before audit log encryption password history was implemented. The keyring ID is audit_log . 

For more information about encrypted audit log files, see Encrypting Audit Log Files. 

The plugin ignores files that have been renamed manually and do not match the pattern, and files that were encrypted with a password no longer available in the keyring. The plugin opens each remaining 

