Shulou(Shulou.com)06/01 Report--

No trigger: this is also the most criticized aspect of other tools. The trigger scheme will have a great impact on the performance of MySQL, and even drag down the main library in serious cases. Lightweight: gh-ost obtains the data table modification operation by pretending to connect from the library, obtains and parses the binary log, and is incremental and controllable to the temporary table insert data, so it has almost no impact on the performance of the MySQL main library. Can be paused: when the original master database is at its peak, you can pause the operation of gh-ost, which means that there are no writes or updates to the master database, which is very popular. Dynamically controllable: the operation of gh-ost can be not only suspended, but also dynamically modified, so you don't have to rerun the whole modification process from scratch after modifying the configuration in various cases, which is very resource-saving. Auditable: the status of gh-ost can be easily obtained, including current task progress, main configuration parameters, relevant MySQL instances, and so on. Gh-ost gets commands by listening to TCP or unix socket files, thus giving operators a great deal of flexibility. Testable: gh-ost supports testing on slave libraries to observe the impact on system load, verify correctness, etc. Every table in the GitHub production environment has been modified and tested many times on the slave library with gh-ost, and they also call on everyone to experience the functions of gh-ost in this way before considering the launch application. High reliability: after full testing, the modification table definition operation of the GitHub production environment has been completed by gh-ost, and it also has functions such as pausing, delayed switching, accurate estimation of task progress, etc. Audit and online control functions can make it easily combined with the monitoring system, which must be very popular with the operation and maintenance staff. Solve the switching problem perfectly: the table switching operation is the last step in modifying the table definition online, and various problems often occur when other tools operate to this stage. Facebook OSC has also analyzed this problem in detail, but its final solution is a non-atomic switch: rename the original table first, and then rename the temporary table on top. Unfortunately, there will be a short period of time when the table does not exist between the two renames, and the business statements run during this period will fail because the target table does not exist. After rigorous demonstration and experiments, Shlomi et al gave a two-stage switching scheme of atomicity: one connection is used to hold the lock, and the other connection is used to do the atomic rename operation. Before the rename operation, a signal table is created to block the rename operation until all required table switching prerequisites are in place. According to this solution, table switching will either succeed and everyone will be happy, or if it fails, there will be no impact on the business, no data loss, and locks will be released to allow the business to continue. DBA only needs to try switching again with gh-ost.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.