MySQL參數說明
If a slave server is very far behind its master, the slave I/O thread can write many relay logs. The slave SQL thread will remove them as soon as it finishes replaying them (you can change this with the relay_log_purge option),
but if it is running far behind, the I/O thread could actually fill up the disk.
The solution to this problem is the relay_log_space_limit configuration variable. If the total size of all the relay logs grows larger than this variable’s size, the I/O thread will stop and wait for the SQL thread to free up some more disk space
log_slave_updates (to make the slave log the replicated events to its own binary log).
Some people enable just the binary log and not log_slave_updates, so they can see
whether anything, such as a misconfigured application, is modifying data on the slave.
如果使用鏈狀同步或者多台Slave之間進行同步則需要開啟此參數。
Initializing a Slave from Another Server
Using mysqldump
If you use only InnoDB tables, you can use the following command to dump
everything from the master, load it all into the slave, and change the slave’s coordinates
to the corresponding position in the master’s binary log:
$ mysqldump --single-transaction --all-databases --master-data=1
--host=server1 | mysql --host=server2
The --single-transaction option causes the dump to read the data as it existed at
the beginning of the transaction. This option may work with other transactional
storage engines as well, but we haven’t tested it. If you’re not using transactional
tables, you can use the --lock-all-tables option to get a consistent dump of
all tables.
Because neither format is perfect for every situation, MySQL 5.1 switches between
statement-based and row-based replication dynamically. By default, it uses
statement-based replication, but when it detects an event that cannot be replicated
correctly with a statement, it switches to row-based replication. You can also control
the format as needed by setting the binlog_format session variable.
Replication Files
mysql-bin.index
A server that has binary logging enabled will also have a file named the same as
the binary logs, but with a .index suffix. This file keeps track of the binary log
files that exist on disk
mysql-relay-bin.index
This file serves the same purpose for the relay logs as the binary log index file
does for the binary logs.
master.info
This file contains the information a slave server needs to connect to its master.
The format is plain text (one value per line) and varies between MySQL versions.
Don’t delete it, or your slave will not know how to connect to its master after it
restarts. This file contains the replication user’s password, in plain text, so you
may want to restrict its permissions.
These files are a rather crude way of recording MySQL’s replication and logging
state. Unfortunately, they are not written synchronously, so if your server loses
power and the files haven’t yet been flushed to disk, they can be inaccurate when the
server restarts.
By default, the binary logs are named after the server’s hostname with a numeric suffix,
but it’s a good idea to name them explicitly in my.cnf, as in the following
example:
log_bin # Don't do this, or files will be named after the hostname
log_bin = mysql-bin # This is safe
沒有留言:
張貼留言