Notes from the main MySQL replication parameters

MySQL master-slave replication parameters Notes

master all the parameters
. 1 = log-bin bin-MySQL 
. 1, the control is turned binlog master record;
2, preferably in a binary file in a separate directory, which is not only easy to optimize, easier maintenance.
3. Rename the binary log is very simple, just change the [mysqld] in the log_bin option,
the following example: To re-adjust logbin the path "/ Home / MySQL / binlog"
[mysqld]
log_bin = / Home / MySQL / binlog / binlog.log

LL / Home / MySQL / the binlog
-rw-RW MySQL MySQL. 1 ---- 98-Mar. 7 17:24 binlog.000001
-rw-RW. 1 ---- 33 is MySQL MySQL-Mar. 7 17:24 binlog.index

Note: be sure to specify the directory to * .log time ends, ie not only to designated folder level, or at the time of restart mysql error.


2. server-id = 1 
the identity of each service server, the master / slave environment, this variable must be different

3. expire_logs_days = 15
This is achieved master automatically delete the binlog

4. the innodb_flush_log_at_trx_commit. 1 = 
This parameter indicates the transaction when submitting, processing redo log way; this variable has three possible values 0, 1:
0: when the transaction commits, the redo log is not written to the transaction log file, but waiting to be flushed once per second
1: when the transaction commits, the redo log buffer is written to disk log file content synchronization, in order to ensure data consistency, use this value in a replication environment.
2: When the transaction commits, the contents of the redo log buffer is written to disk asynchronous log file (written to the file system cache)
recommended = 1 must be set innodb_flush_log_at_trx_commit 

5.sync_binlog 1 = 
1, this parameter indicates how many times on each write buffer synchronization to disk;
2, sync_binlog = 1 represents a synchronous write buffer and disk binary log file, do not use the file system cache
when using innodb transaction engine, in a replication environment, in order to ensure maximum availability, are set to "1", but It will affect the performance of io.
3, even if set to "1", there will be a problem:
If the binary log when written to disk, but the transaction has not yet commit, this time down,
when the service up again restored, and the recording can not be rolled back to binary contents of the log uncommitted;
this time will result in inconsistent master and slave data
Solution:
the need to ensure the parameters innodb_support_xa = 1. Recommendations must set

6 .innodb_support_xa = 1
This parameter is related to XA transaction, which guarantees innodb data files and binary log synchronization, replication to ensure data consistency environment. Recommendations must set

7.binlog-do-db = skate_db
only the specified database record update binary log

8. binlog-do-table = skate_tab
only updates the specified table records into binary log

9. binlog-ignore-db = skate_db
ignore the specified database update log binary

10.log_slave_updates = 1
this parameter controls whether the slave from the master database log and records the received content in the execution of this slave binary log for the slave
in a cascade replication environment (including bis master environment), this parameter is required

11.binlog_format = statement | row | mixed
control records the contents of binary logs in what format, the default is Mixed

12. max_binlog_size
the size of each of the master binary log file, the default 1G

13.binlog_cache_size
1 All uncommitted transactions will be recorded in a cache or temporary files, to be submitted to the unified synchronous binary log,
2, this variable is based on the session, and each session is open binlog_cache_size a cache size.
3, by setting the size of the variable binlog_cache_size "Binlog_cache_disk_use" and "Binlog_cache_use".
Description:
Binlog_cache_disk_use: Temporary files written using the binary log number
Binlog_cache_use: frequency of use in mind to write binary buffer

14.auto_increment_increment = 2 // growth step
auto_increment_offset = 1 // starting position
in a dual master key environment can prevent conflict

 

slave The parameters
1.server-id = 2
and meanings as the master, the service identifier

2.log-bin = mysql-bin 
and meaning as the master, the binary opening

3.relay-log = relay-bin 
relay log file path name

4. relay-log-index = relay  -bin
path name of the relay log index file

5. log_slave_updates = 1 
and master the meanings as described above

6.read_only =. 1
. 1, so that the read-only databases, this parameter in the slave replication environment and user having super authority ineffective,
2,. 1 = READ_ONLY useful for replicating a set environment, it can guarantee the master slave only accept updated, the client does not accept the update.
3, client settings:
mysq>, Ltd. Free Join the SET READ_ONLY = 1

7. skip_slave_start
the slave does not start the replication process when starting mysql, mysql after using the start slave start up recommendations must

8.replicate-do-db 
copy only specified db

9. replicate-do-table
copy only the specified table

10. replicate-ingore-table
designation is ignored table

11. replicate_wild_do_table = skatedb.%
Fuzzy match specified replication DB

12. The auto_increment_increment = 2
auto_increment_offset =. 1
and master meaning as described above with reference 

13. log_slow_slave_statements 
turned on Slave slow query log, at query time is greater than long_query_time, recorded slow query log

14. a max_relay_log_size
relay log on Slave size, default. 1G

15.relay_log_info_file
path name of the relay status information log file

16. relay_log_purge
deleted when the relay log is not needed, the default is oN
the SET = the GLOBAL relay_log_purge. 1

. 17 .replicate-rewrite-db = from_name->  to_name
redirection database, sub-libraries can be aggregated to the master database for statistical analysis

 

Hope to help little friends ~ ~ ~

 

Guess you like

Origin www.cnblogs.com/jimoyu/p/12502777.html