Thank you. I read the patches for the bug, and it appeared to me that setting "SET GLOBAL audit_log_flush='ON';" may now result in a condition in which the log mutex is grabbed, but not released when flushing fails. This said, I my understanding of the code changes could be in error, I am not an expert C programmer.
Regarding audit log settings. All were defaults for PS 5.5.40. I simply installed/loaded the audit_log dynamically, leaving all the audit log variables to defaults. These did not persist across reboot, however I believe the variables would have been:
|audit_log_buffer_size = 1048576
|audit_log_file = audit.log
audit_log_flush = OFF
|audit_log_format = OLD
|audit_log_policy = ALL
|audit_log_rotate_on_size = 0
|audit_log_rotations = 0
|audit_log_strategy = ASYNCHRONOUS
Presently we have stopped using the audit log on our production servers until our root cause analysis is complete and we are confident the using the audit log will not cause the MySQL to hang again.
Hi Sergei,
Thank you. I read the patches for the bug, and it appeared to me that setting "SET GLOBAL audit_log_ flush=' ON';" may now result in a condition in which the log mutex is grabbed, but not released when flushing fails. This said, I my understanding of the code changes could be in error, I am not an expert C programmer.
Regarding audit log settings. All were defaults for PS 5.5.40. I simply installed/loaded the audit_log dynamically, leaving all the audit log variables to defaults. These did not persist across reboot, however I believe the variables would have been:
|audit_ log_buffer_ size = 1048576 log_rotate_ on_size = 0 log_rotations = 0
|audit_log_file = audit.log
audit_log_flush = OFF
|audit_log_format = OLD
|audit_log_policy = ALL
|audit_
|audit_
|audit_log_strategy = ASYNCHRONOUS
Presently we have stopped using the audit log on our production servers until our root cause analysis is complete and we are confident the using the audit log will not cause the MySQL to hang again.
Thank you.
respectfully,
Marc ODell