New sharing of master-slave replication and synchronization in the InnoDB engine database

Recently, the company's MySQL architecture has been upgraded, from the original one-master-many slave to the DRBD + Heartbeat dual-master-many slave, and a new e-commerce website project is coming soon, DRBD + Heartbeat dual master and one slave are used. Because this process is different from the previous MyISAM engine, I will summarize my experiences here:
1) The replication process of MySQL is an asynchronous synchronization process, not completely master-slave synchronization, so there is a delay in the synchronization process. If the read/write splitting service is enabled, we recommend that you monitor the delay;
2) the master and slave machines of MySQL should remember that the server-id should be inconsistent. If the same, the following error will occur during replication:
Fatal error: The slave I/O thread stops because master and slavehave equal MySQL server ids; these ids must be different for replication to work (or the -- replicate-same-server-id option must be used on slave but this doesnot always make sense; please check the manual before using it ).
This problem is well handled. Change the server-id of the server Load balancer to be different from that of the master machine.
3) one of my previous mistakes is that the slave machine uses its own binary log to complete the replication process. In fact, this is not the case. According to the working principle of replication: the slave server is to copy the binary log of the master server to its own relay log, that is, the relay-log (that is, the name of the centos3-relay-bin.000002), and then apply the update application to its own database, therefore, the slave machine does not need to enable binary logs, so the process will be successful. unless the master architecture is prepared, the slave machine needs to enable binary logs, this problem has always led me to think that binary must be enabled when the slave machine builds the replication environment,
4) When authorizing on the master machine, try to grant only one or several fixed machine permissions so that they only have the replication slav and replication client permissions, and try not to grant permissions. In addition, although the database is generally operated through the Intranet, the more we authorize the MySQL database over the Intranet, the more we should pay attention to security;
5) if the replication construction process follows the normal process, it is generally easy to implement successfully. If an error occurs, check the network environment and permissions, generally, the entire construction process should be smooth.
At the early stage of database design, I have defined the e-commerce database engine as InnoDB. In addition to the original system tables in the database, all other tables are converted from MyISAM to InnoDB for two reasons:
1) e-commerce businesses involve transaction payment. In such basic OLTP applications, InnoDB should be the preferred storage engine for core application tables;
2) When the DRBD system is restarted, the process will be slow and the table will be read frequently. If the table engine is MyISAM, it is very likely to be damaged. In order to cause unnecessary problems, I converted the table engine of the database from MyISAM to the table of the InnoDB engine.
DRBD + Heartbeat + MySQL refer to the previous working documents and the setup was successful. The error 1062 was reported when the replication environment was set up. The detailed process is as follows:
In the initial stage, refer to the MySQL manual for operations. Take the snapshot backup of the master machine and use the -- single-transaction option. Then, 1062 errors are frequently reported during synchronization. The error log is as follows:
Last_ SQL _Error: Error 'duplicate entry 'd36ad91bff36308de540bbd9ae6f4279 'for key'primary'' on query. default database: 'myproject '. query: 'insert INTO 'Lee _ session' ('session _ id', 'IP _ address', 'user _ agent', 'last _ activity ', 'User _ data') VALUES ('d36ad91bff36308de540bbd9ae6f4279 ', '2017. 153.201.218 ', 'mozilla/123', 4.0 ,'')'
Later, I changed my mind and used the -- master-data option to take the master snapshot for backup. The command is as follows:
Mysqldump-uroot -- quick -- flush-logs -- master-data = 1-p myproject> myproject. SQL