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
+33-27Lines changed: 33 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,20 @@
1
1
# Binary logs and replication improvements
2
2
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.
3
+
Due to continuous development, Percona Server for MySQL has incorporated a number of improvements related to replication and binary log handling. These improvements result in replication-specific behaviors that distinguish Percona Server for MySQL from standard MySQL.
5
4
6
5
## Statements with a `LIMIT` clause
7
6
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.
7
+
In MySQL 8.4, 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
8
10
9
Here's why:
11
10
12
11
* The LIMIT clause without an ORDER BY makes the result set non-deterministic
13
12
14
13
* The same statement might affect different rows on the primary and replicas
15
14
16
-
```{.bash}
15
+
Run these example statements in the MySQL client:
16
+
17
+
```sql
17
18
UPDATE table1 LIMIT10SET col1 ='value';
18
19
DELETEFROM table1 LIMIT5;
19
20
INSERT INTO table2 SELECT*FROM table1 LIMIT3;
@@ -25,7 +26,9 @@ To make these statements safe for statement-based replication, you should do one
25
26
26
27
* Add an ORDER BY clause to make the result set deterministic
27
28
28
-
```{.bash}
29
+
Run these example statements in the MySQL client:
30
+
31
+
```sql
29
32
UPDATE table1 SET col1 ='value'ORDER BY id LIMIT10;
30
33
DELETEFROM table1 ORDER BY id LIMIT5;
31
34
INSERT INTO table2 SELECT*FROM table1 ORDER BY id LIMIT3;
@@ -86,7 +89,7 @@ log.
86
89
87
90
The `binlog_skip_flush_commands` setting does not impact the following commands because they are never recorded in the binary log:
88
91
89
-
*`FLUSH LOGS`
92
+
*`FLUSH LOGS`
90
93
91
94
*`FLUSH BINARY LOGS`
92
95
@@ -130,7 +133,7 @@ When enabled, all single-table `DROP TABLE` DDL statements are logged in the bin
130
133
131
134
You can enable `binlog_ddl_skip_rewrite` at runtime:
132
135
133
-
```{.bash}
136
+
```sql
134
137
-- Check current setting
135
138
SHOW VARIABLES LIKE'binlog_ddl_skip_rewrite';
136
139
@@ -156,9 +159,9 @@ After making this change, restart the MySQL service for it to take effect.
156
159
157
160
### Example usage
158
161
159
-
The following code block demonstrates how to enable `binlog_ddl_skip_rewrite` and shows the feature's effect on a `DROP TABLE` statement:
162
+
The following code demonstrates how to enable `binlog_ddl_skip_rewrite` and shows the feature's effect on a `DROP TABLE` statement. Run these commands in the MySQL client:
160
163
161
-
```{.bash}
164
+
```sql
162
165
SET binlog_ddl_skip_rewrite =ON;
163
166
/*comment at start*/DROPTABLEt/*comment at end*/;
164
167
```
@@ -189,19 +192,22 @@ Before using the `binlog_utils_udf` component, ensure the following requirements
189
192
190
193
Install the component on each server where you plan to use these functions:
0 commit comments