[MDEV-18885] log_bin_basename config option is missing in 10.2 series Created: 2019-03-11  Updated: 2020-12-17  Resolved: 2019-03-11

Status: Closed
Project: MariaDB Server
Component/s: Configuration
Affects Version/s: 10.2.18
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Max ulidtko Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-7110 Add missing MySQL variable log_bin_ba... Closed

 Description   

Hi!
This issue MDEV-7110 has been fixed, it seems, in 10.1.6 – but on MariaDB 10.2.18 log_bin_basename is still not recognized:

2019-03-11 18:08:17 139891721672896 [ERROR] /usr/sbin/mysqld: unknown variable 'log_bin_basename=geo-master'

I wonder if the fix was somehow applied only to 10.1 branch, and not to trunk/master?..

One more quicktest (notice lack of log_bin_basename):

$ mysqld --version; mysqld --verbose --help | grep basename
 
mysqld  Ver 10.2.18-MariaDB-log for Linux on x86_64 (MariaDB Server)
 
  --log-basename=name Basename for all log files and the .pid file. This sets
 
                      'datadir'/'log-basename'-bin or 'datadir'/mysql-bin will
 
                      be used (the later if --log-basename is not specified).
 
                      We strongly recommend to use either --log-basename or
 
                      not specified then 'datadir'/'log-basename'.err or the
 
log-basename                                               geo-master

This is a simple bug, but it forces us to use log_basename instead, and consequently script up a kludge to reset back log_error, the slow log, pid file locations... back to their previous values once we set up replication.

 Comments   
Comment by Elena Stepanova [ 2019-03-11 ]

MDEV-7110 added the system variable, it didn't add the startup option. The variable is documented as such and exists in 10.2 as well.
It is not a startup option in MySQL, either.

Comment by Max ulidtko [ 2019-03-12 ]

@Elena, oh, I've misread the docs. Thanks for quick triage.

Comment by w bob [ 2020-12-17 ]

the nuance for the uninitiated here is the docs declare the variable "Read Only". I oversaw that detail at first and admit I didn't expect un-editable variables. I think a forgiving log message could've lead me on quickly.

"$sys_var is a read-only system variable, please remove from config file"

Generated at Thu Feb 08 08:47:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.