Analysis of parameter SQL_SLAVE_SKIP_COUNTER
This article introduces the relevant knowledge of "the analysis of parameter SQL_SLAVE_SKIP_COUNTER". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!
After each database replication conflict, a command that is frequently used is as follows:
SET SQL_SLAVE_SKIP_COUNTER = 1
Skipping the wrong event can solve it, but it's not.
In binlog, all binlog is divided into groups, and each group is a transactional binlog generated by its main library, starting with begin and ending with commit. Depending on the type of time, it is as follows:
Begin statement: for a binlog group, starting with begin and ending with commit, different SQL_SLAVE_SKIP_COUNTER can be handled differently. If the parameter SQL_SLAVE_SKIP_ count value is 1, then all events in this group are counted as uncounted events, that is, this 1 represents a transaction, not an event, and count 1 is reduced to 0 only when a commit statement is encountered, and the next transaction group executes normally. If the parameter SQL_SLAVE_SKIP_COUNTER value is greater than 1, then the events in this group are considered individual events, and when one event is processed, the value of the parameter SQL_SLAVE_SKIP_COUNTER is subtracted by 1. When it is reduced to 1, if the transaction group is not finished, go back to the above, skip the case with a value of 1, if it is over, but not reduced to 0, then the next transaction group will continue to reprocess.
Commit or Rollback statement: when this statement is encountered, the value of the parameter SQL_SLAVE_SKIP_COUNTER will be subtracted by 1 in any case. If the value of SQL_SLAVE_SKIP_COUNTER is 1, all the time before commit will be counted as uncounted events. Minus 1 here, the skip of a transaction is completed.
Other Query statements: when SQL_SLAVE_SKIP_COUNTER is 1, all events in the group will be skipped, otherwise it will be subtracted by 1.
Rows event: this type is the event type of a row in row mode. Count several events generated by a SQL statement. If the SQL_SLAVE_SKIP_COUNTER set is greater than 1, it will be subtracted by 1 for each event, and if it is reduced to 1 or set to 1, it will not be counted until after the commit event, and all previous operations will not be counted.
Do not count events: this type means that whenever such an event is encountered and SQL_SLAVE_SKIP_COUNTER is set to 1 or decremented to 1, it is skipped and does not affect the value of SQL_SLAVE_SKIP_COUNTER. If you set a SQL_SLAVE_SKIP_COUNTER value greater than 1, the count is decremented by 1, and such events are not counted until it is decremented to 1. This type of events include Table_map, Intvar, Rand, User_var, and BEGIN_load, so if there are these five events in binlog, they are not counted in the count and simply ignored.
The content of "Analysis of Parameter SQL_SLAVE_SKIP_COUNTER" ends here. Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!
