Several options control such properties as the name of the binlog
files and the index file. Most of these options can be manipulated as
server variables as well.
expire-log-days= days
The number of days that binlog files should be kept. Files that are
older than the specified number will be purged from the filesystem
when the binary log is rotated or the server restarts.
By default this option is 0, meaning that binlog files are
never removed.
log-bin[= basename]
The binary log is turned on by adding the log-bin option in the my.cnf file. In addition to turning
on the binary log, this option gives a base name for the binlog
files; that is, the portion of the filename before the dot. If an
extension is provided, it is removed when forming the base name of
the binlog files.
If the option is specified without a
basename, the base name defaults
to host-bin where host
is the base name—that is, the filename without directory or extension—of the file given by
the pid-file option,
which is usually the hostname as given by
gethostname(2). For example, if pid-file is /usr/run/mysql/master.pid, the default
name of the binlog files will be master-bin.000001, master-bin.000002, etc.
Since the default value for the pid-file option includes the hostname, it
is strongly recommended that you give a value to the log-bin option. Otherwise the binlog files
will change names when the hostname changes (unless pid-file is given an explicit
value).
log-bin-index[= filename]
Gives a name to the index file. This can be useful if you want to
place the index file in a different place from the default.
The default is the same as the base name used for log-bin. For example, if the base name
used to create binlog files is master-bin, the index file will be named
master-bin.index.
Similar to the situation for the log-bin option, the hostname will be used
for constructing the index filename, meaning that if the hostname
changes, replication will break. For this reason, it is strongly
recommended that you provide a value for this option.
log-bin-trust-function-creators
When creating stored functions, it is possible to create specially
crafted functions that allow arbitrary data to be read and
manipulated on the slave. For this reason, creating stored functions
requires the SUPER privilege.
However, since stored functions are very useful in many
circumstances, it might be that the DBA trusts anyone with CREATE ROUTINE privileges not to write
malicious stored functions. For this reason, it is possible to
disable the SUPER privilege
requirement for creating stored functions (but CREATE ROUTINE is still required).
binlog-cache-size= bytes
The size of the in-memory part of the transaction cache in
bytes. The transaction cache is backed by disk, so whenever the size
of the transaction cache exceeds this value, the remaining data will
go to disk.
This can potentially create a performance problem, so
increasing the value of this option can improve performance if you
use many large transactions.
Note that just allocating a very large buffer might not be a
good idea, since that means that other parts of the server get less
memory, which might cause performance degradation.
max-binlog-cache-size= bytes
Use this option to restrict the size of each transaction in the
binary log. Since large transactions can potentially block the
binary log for a long time, they will cause other threads to convoy
on the binary log and can therefore create a significant performance
problem. If the size of a transaction exceeds
bytes, the statement will be aborted with
an error.
max-binlog-size= bytes
Specifies the size of each binlog file. When writing a statement or
transaction would exceed this value, the binlog file is rotated and
writing proceeds in a new, empty binlog file.
Notice that if the transaction or statement exceeds max-binlog-size, the binary log will be
rotated, but the transaction will be written to the new file in its
entirety, exceeding the specified maximum. This is because
transactions are never split between binlog files.
sync-binlog= period
Specifies how often to write the binary log to disk using
fdatasync(2). The value given is the number of
transaction commits for each real call to
fdatasync(2). For instance, if a value of 1 is
given, fdatasync(2) will be called for each
transaction commit, and if a value of 10 is given,
fdatasync(2) will be called after each 10
transaction commits.
A value of zero means that there will be no calls to
fdatasync(2) at all and that the server trusts
the operating system to write the binary log to disk as part of the
normal file handling.
read-only
Prevents any client threads—except the slave thread and users
with SUPER privileges—from updating any data on
the server. This is useful on slave servers to allow replication to
proceed without data being corrupted by clients that connect to the
slave.
