Use TIPS for temporary tables in replication

TIPS is used for temporary tables in replication. We know that temporary tables have the following features: 1. At the SESSION level, once the SESSION is disconnected, it will be automatically dropped. 2. It depends on the default engine. If the default engine is INNODB, And you are crazy about using temporary tables. Then, your IBDATA will be infinitely increased. 3. Like the disk table, the data is written to the binlog by default, and the rollback plan is passively added. Imagine the following scenario: database corruption and no backup. The binary logs are all well preserved and happy. Import binary logs to MYSQL. Www.2cto.com
There are two methods: 1) mysqlbinlog... *. log | mysql dbname; this method uses the pipeline to directly restore data, which takes a short time and is highly efficient. However, if there are a bunch of temporary tables in the middle of the log, the Import fails. (Remember the features of the temporary table .) 2) mysqlbinlog ..... *. log> result. log; mysql dbname <result. log; this is a long time, low efficiency, high disk space occupation, and a waste of system resources. However, the import is successful. If there are a large number of temporary table applications, the correct method should be adopted in master-slave replication: (as I mentioned in the past 08 years .) When writing data, of course, only the host is used here. Whether you are managing MYSQL in an application or using a client, you should do the following:
[SQL] SET SQL _LOG_BIN = 0; Disable SESSION-level replication. Update tmp_t1, tmp_t2 set...; drop tmp_t1; www.2cto.com drop tmp_t2; SET SQL _LOG_BIN = 1; enable SESSION-level replication.