Several important startup options for MySQL master-slave replication
(1) log-slave-updates
The log-slave-updates parameter is used to configure whether the updates of the slave server are written to the binary log. This option is not enabled by default. However, if the slave server B is the slave server of server A, it also serves as the master server of server C. , then this option needs to be developed so that its slave C can get its binary log for synchronization operations
(2) master-connect-retry
The parameter master-connect-retry is used to set the retry interval when the connection to the master server is lost. The default is 60 seconds.
(3) read-only
Read-only is used to limit the update operation of the slave database by ordinary users to ensure the security of the slave database, but if it is a super user, it can still update the slave database.
(4) slave-skip-errors
During the replication process, due to various reasons, the slave server may encounter an error in executing the SQL in the BINLOG. By default, the server will stop the replication process and no longer perform synchronization until the user handles it by himself.
The role of Slave-skip-errors is to define the error number that the slave server can automatically skip during the replication process. When the defined error number is encountered during the replication process, it can be automatically skipped and the following SQL statement can be executed directly.
--slave-skip-errors=[err1,err2,…….|ALL]
However, it must be noted that if this parameter is activated improperly, it is likely to cause the data of the master and slave databases to be out of sync. In the application, it needs to be based on the actual situation. If the data integrity requirements are not very strict, then this option can indeed reduce maintenance. the cost of