You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/binlogging-replication-improvements.md
+97-35
Original file line number
Diff line number
Diff line change
@@ -1,39 +1,57 @@
1
1
# Binary logs and replication improvements
2
2
3
3
Due to continuous development, Percona Server for MySQL incorporated a number of
4
-
improvements related to replication and binary logs handling. This resulted in replication specifics, which distinguishes it from *MySQL*.
4
+
improvements related to replication and binary logs handling. This resulted in replication specifics, which distinguishes it from MySQL.
5
5
6
-
## Safety of statements with a `LIMIT` clause
6
+
## Statements with a `LIMIT` clause
7
7
8
-
### Summary of the fix
8
+
In MySQL 8.0, any UPDATE/DELETE/INSERT ... SELECT statements that include a LIMIT clause are indeed considered unsafe for statement-based replication. These statements will cause MySQL to automatically switch from statement-based logging to row-based logging if binlog_format is set to MIXED.
9
9
10
-
*MySQL* considers all `UPDATE/DELETE/INSERT ... SELECT` statements with
11
-
`LIMIT` clause to be unsafe, no matter wether they are really producing
12
-
non-deterministic result or not, and switches from statement-based logging
13
-
to row-based one. *Percona Server for MySQL* is more accurate, it acknowledges such
14
-
instructions as safe when they include `ORDER BY PK` or `WHERE`
15
-
condition. This fix has been ported from the upstream bug report
## Performance improvement on relay log position update
12
+
* The LIMIT clause without an ORDER BY makes the result set non-deterministic
19
13
20
-
### Relay log position fix
14
+
* The same statement might affect different rows on the primary and replicas
15
+
16
+
```sql
17
+
UPDATE table1 LIMIT10SET col1 ='value';
18
+
DELETEFROM table1 LIMIT5;
19
+
INSERT INTO table2 SELECT*FROM table1 LIMIT3;
20
+
```
21
+
22
+
To make these statements safe for statement-based replication, you should do one of the following:
23
+
24
+
* Remove the LIMIT clause
25
+
26
+
* Add an ORDER BY clause to make the result set deterministic
27
+
28
+
```sql
29
+
UPDATE table1 SET col1 ='value'ORDER BY id LIMIT10;
30
+
DELETEFROM table1 ORDER BY id LIMIT5;
31
+
INSERT INTO table2 SELECT*FROM table1 ORDER BY id LIMIT3;
32
+
```
33
+
34
+
The exception is when the LIMIT is used with an ORDER BY clause that uses a unique key - in this case, the statement becomes deterministic and safe for statement-based replication.
35
+
36
+
Percona Server for MySQL acknowledges statements as safe when they include either an `ORDER BY PK` or `WHERE`
37
+
condition.
38
+
39
+
40
+
## Relay log position fix
21
41
22
42
*MySQL* always updated relay log position in multi-source replications setups
23
43
regardless of whether the committed transaction has already been executed or
24
44
not. Percona Server omits relay log position updates for the already logged
25
45
GTIDs.
26
46
27
-
###Relay log position details
47
+
## Relay log position details
28
48
29
49
Particularly, such unconditional relay log position updates caused additional
30
50
fsync operations in case of `relay-log-info-repository=TABLE`, and with the
31
51
higher number of channels transmitting such duplicate (already executed)
32
52
transactions the situation became proportionally worse. Bug fixed [#1786](https://jira.percona.com/browse/PS-1786), (upstream [#85141](https://bugs.mysql.com/bug.php?id=85141)).
33
53
34
-
## Performance improvement on source and connection status updates
35
-
36
-
### Source and connection status update fix
54
+
## Source and connection status update fix
37
55
38
56
Replica nodes configured to update source status and connection information
39
57
only on log file rotation did not experience the expected reduction in load.
@@ -43,7 +61,7 @@ replication when replica had to skip the already executed GTID event.
43
61
## Write `FLUSH` commands to the binary log
44
62
45
63
`FLUSH` commands, such as `FLUSH SLOW LOGS`, are not written to the
46
-
binary log if the system variable binlog_skip_flush_commands is set
64
+
binary log if the system variable `binlog_skip_flush_commands` is set
47
65
to **ON**.
48
66
49
67
In addition, the following changes were implemented in the behavior of
@@ -71,17 +89,32 @@ regardless of the value of the binlog_skip_flush_commands variable.
71
89
| Dynamic | Yes |
72
90
| Default | OFF |
73
91
74
-
When binlog_skip_flush_commands is set to **ON**, `FLUSH ...` commands are not written to the binary
75
-
log. See Writing FLUSH Commands to the Binary Log for more information
76
-
about what else affects the writing of `FLUSH` commands to the binary log.
92
+
When `binlog_skip_flush_commands` is set to **ON**, `FLUSH ...` commands are not written to the binary
93
+
log.
94
+
95
+
The `binlog_skip_flush_commands` setting does not affect the following commands because they are not written to binary log:
96
+
97
+
• `FLUSH LOGS`
98
+
99
+
• `FLUSH BINARY LOGS`
100
+
101
+
• `FLUSH TABLES WITH READ LOCK`
102
+
103
+
• `FLUSH TABLES ... FOR EXPORT`
104
+
77
105
78
-
!!! note
106
+
The `FLUSH` command does not record to the binary log, and it ignores the `binlog_skip_flush_commands` value when you run it with the `NO_WRITE_TO_BINLOG` keyword (or its alias `LOCAL`).
79
107
80
-
`FLUSH LOGS`, `FLUSH BINARY LOGS`, `FLUSH TABLES WITH READ LOCK`, and `FLUSH TABLES ... FOR EXPORT` are not written to the binary log no matter what value the binlog_skip_flush_commands variable contains. The `FLUSH` command is not recorded to the binary log and the value of binlog_skip_flush_commands is ignored if the `FLUSH` command is run with the `NO_WRITE_TO_BINLOG` keyword (or its alias `LOCAL`).
108
+
## Keep comments with DDL commands
81
109
82
-
## Maintaining comments with DROP TABLE
110
+
When you run a DDL command, such as `DROP TABLE`, the server does the following in the binary log.
83
111
84
-
When you issue a `DROP TABLE` command, the binary log stores the command but removes comments and encloses the table name in quotation marks. If you require the binary log to maintain the comments and not add quotation marks, enable `binlog_ddl_skip_rewrite`.
112
+
| Actions | Description |
113
+
|---|---|
114
+
| Removes Comments | The server deletes any comments in the original command. For example, if you use `DROP TABLE my_table /* This is a comment */;`, the binary log does not save the comment. |
115
+
| Adds Quotation Marks | The server puts quotation marks around the table name. So, if you run `DROP TABLE my_table;`, it logs it as `DROP TABLE "my_table";`. |
116
+
117
+
These actions simplify the logging format, but sometimes, you want the original format.
85
118
86
119
### binlog_ddl_skip_rewrite
87
120
@@ -93,7 +126,38 @@ When you issue a `DROP TABLE` command, the binary log stores the command but rem
93
126
| Dynamic | Yes |
94
127
| Default | OFF |
95
128
96
-
If the variable is enabled, single table `DROP TABLE` DDL statements are logged in the binary log with comments. Multi-table `DROP TABLE` DDL statements are not supported and return an error.
129
+
When disabled (default setting), the server removes comments and adds quotation marks.
130
+
131
+
If the variable is enabled, all single table `DROP TABLE` DDL statements are logged in the binary log with the following:
132
+
133
+
• Comments are preserved, so any notes you add to the command stay in the binary log.
134
+
135
+
• Quotation marks are not added.
136
+
137
+
138
+
You can enable `binlog_ddl_skip_rewrite` at runtime:
139
+
140
+
```sql
141
+
-- Check current setting
142
+
SHOW VARIABLES LIKE'binlog_ddl_skip_rewrite';
143
+
144
+
-- Enable feature
145
+
SET GLOBAL binlog_ddl_skip_rewrite =ON;
146
+
147
+
-- Disable feature
148
+
SET GLOBAL binlog_ddl_skip_rewrite = OFF;
149
+
```
150
+
151
+
You can enable it permanently by adding it to the my.cnf configuration file:
152
+
153
+
```text
154
+
[mysqld]
155
+
binlog_ddl_skip_rewrite = ON
156
+
```
157
+
158
+
After adding the statement to the configuration file, restart the MySQL service.
159
+
160
+
Multi-table `DROP TABLE` DDL statements are not supported and return an error.
97
161
98
162
```sql
99
163
SET binlog_ddl_skip_rewrite =ON;
@@ -113,9 +177,7 @@ To implement Point in Time recovery, we have added the `binlog_utils_udf`. The f
113
177
| get_first_record_timestamp_by_binlog() | Timestamp as INTEGER | Returns the timestamp of the first event in the specified binlog |
114
178
| get_last_record_timestamp_by_binlog() | Timestamp as INTEGER | Returns the timestamp of the last event in the specified binlog |
115
179
116
-
!!! note
117
-
118
-
All functions returning timestamps return their values as microsecond precision UNIX time. In other words, they represent the number of microseconds since 1-JAN-1970.
180
+
All functions returning timestamps return their values as microsecond precision UNIX time. In other words, they represent the number of microseconds since 1-JAN-1970.
119
181
120
182
All functions accepting a binlog name as the parameter accepts only short names, without a path component. If the path separator (‘/’) is found in the input, an error is returned. This serves the purpose of restricting the locations from where binlogs can be read. They are always read from the current binlog directory ([@@log_bin_basename system variable]).
121
183
@@ -127,7 +189,7 @@ The basic syntax for `get_binlog_by_gtid()` is the following:
127
189
128
190
Usage: SELECT get_binlog_by_gtid(string) [AS] alias
129
191
130
-
Example:
192
+
An example of using the `get_binlog_gtid` command:
0 commit comments