Skip to content

Commit 364a8bd

Browse files
authored
Merge pull request #617 from percona/ps-10352-8.4
PS-10352 [DOCS] Binary logs and replication improvements documentatio…
2 parents 740a658 + 6d28dc1 commit 364a8bd

File tree

1 file changed

+33
-27
lines changed

1 file changed

+33
-27
lines changed

docs/binlogging-replication-improvements.md

Lines changed: 33 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,20 @@
11
# Binary logs and replication improvements
22

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.
54

65
## Statements with a `LIMIT` clause
76

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.
98

109
Here's why:
1110

1211
* The LIMIT clause without an ORDER BY makes the result set non-deterministic
1312

1413
* The same statement might affect different rows on the primary and replicas
1514

16-
```{.bash}
15+
Run these example statements in the MySQL client:
16+
17+
```sql
1718
UPDATE table1 LIMIT 10 SET col1 = 'value';
1819
DELETE FROM table1 LIMIT 5;
1920
INSERT INTO table2 SELECT * FROM table1 LIMIT 3;
@@ -25,7 +26,9 @@ To make these statements safe for statement-based replication, you should do one
2526

2627
* Add an ORDER BY clause to make the result set deterministic
2728

28-
```{.bash}
29+
Run these example statements in the MySQL client:
30+
31+
```sql
2932
UPDATE table1 SET col1 = 'value' ORDER BY id LIMIT 10;
3033
DELETE FROM table1 ORDER BY id LIMIT 5;
3134
INSERT INTO table2 SELECT * FROM table1 ORDER BY id LIMIT 3;
@@ -86,7 +89,7 @@ log.
8689

8790
The `binlog_skip_flush_commands` setting does not impact the following commands because they are never recorded in the binary log:
8891

89-
* `FLUSH LOGS`
92+
* `FLUSH LOGS`
9093

9194
* `FLUSH BINARY LOGS`
9295

@@ -130,7 +133,7 @@ When enabled, all single-table `DROP TABLE` DDL statements are logged in the bin
130133

131134
You can enable `binlog_ddl_skip_rewrite` at runtime:
132135

133-
```{.bash}
136+
```sql
134137
-- Check current setting
135138
SHOW VARIABLES LIKE 'binlog_ddl_skip_rewrite';
136139

@@ -156,9 +159,9 @@ After making this change, restart the MySQL service for it to take effect.
156159

157160
### Example usage
158161

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:
160163

161-
```{.bash}
164+
```sql
162165
SET binlog_ddl_skip_rewrite = ON;
163166
/*comment at start*/DROP TABLE t /*comment at end*/;
164167
```
@@ -189,19 +192,22 @@ Before using the `binlog_utils_udf` component, ensure the following requirements
189192

190193
Install the component on each server where you plan to use these functions:
191194

192-
```{.bash}
195+
```sql
193196
INSTALL COMPONENT 'file://component_binlog_utils_udf';
194197
```
195198

196199
#### Verify installation
197200

198-
```{.bash}
201+
Run this command in the MySQL client:
202+
203+
```sql
199204
SELECT * FROM mysql.component WHERE component_urn = 'file://component_binlog_utils_udf';
200205
```
201206

202-
```{.bash}
203-
SELECT ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES
204-
-> WHERE ROUTINE_NAME LIKE 'get_%' AND ROUTINE_TYPE = 'FUNCTION';
207+
Alternatively, run this command to view all installed components:
208+
209+
```sql
210+
SELECT * FROM mysql.component;
205211
```
206212

207213
### Available functions
@@ -271,7 +277,7 @@ The following examples demonstrate how to use each function. Replace the sample
271277

272278
Use `get_binlog_by_gtid()` to locate which binary log file contains a specific transaction:
273279

274-
```{.bash}
280+
```sql
275281
SELECT CAST(get_binlog_by_gtid('550e8400-e29b-41d4-a716-446655440000:123') AS CHAR) AS binlog;
276282
```
277283

@@ -281,7 +287,7 @@ Use case: When you know a specific GTID and need to find which binary log file c
281287

282288
Use `get_last_gtid_from_binlog()` to find the final transaction in a specific binary log file:
283289

284-
```{.bash}
290+
```sql
285291
SELECT CAST(get_last_gtid_from_binlog('binlog.000001') AS CHAR) AS last_gtid;
286292
```
287293

@@ -291,7 +297,7 @@ Use case: Determine the last transaction processed in a binary log file before r
291297

292298
Use `get_gtid_set_by_binlog()` to retrieve all GTIDs contained in a specific binary log file:
293299

294-
```{.bash}
300+
```sql
295301
SELECT CAST(get_gtid_set_by_binlog('binlog.000001') AS CHAR) AS gtid_set;
296302
```
297303

@@ -301,7 +307,7 @@ Use case: Get a complete list of all transactions in a binary log file for analy
301307

302308
Use `get_binlog_by_gtid_set()` to find the first binary log file that contains any GTID from a specified set:
303309

304-
```{.bash}
310+
```sql
305311
SELECT CAST(get_binlog_by_gtid_set('550e8400-e29b-41d4-a716-446655440000:7,550e8400-e29b-41d4-a716-446655440000:8') AS CHAR) AS binlog;
306312
```
307313

@@ -316,12 +322,12 @@ Use timestamp functions to determine when events occurred in binary log files. T
316322
Find when the first event was written to a binary log file:
317323

318324
=== "Raw Timestamp (Microseconds)"
319-
```{.bash}
325+
```sql
320326
SELECT CAST(get_first_record_timestamp_by_binlog('binlog.000001') AS UNSIGNED) AS raw_ts;
321327
```
322328

323329
=== "Human-Readable Format"
324-
```{.bash}
330+
```sql
325331
SELECT FROM_UNIXTIME(
326332
CAST(get_first_record_timestamp_by_binlog('binlog.000001') AS UNSIGNED) DIV 1000000
327333
) AS first_event_ts;
@@ -334,12 +340,12 @@ Use case: Determine when a binary log file started receiving events, useful for
334340
Find when the last event was written to a binary log file:
335341

336342
=== "Raw Timestamp (Microseconds)"
337-
```{.bash}
343+
```sql
338344
SELECT CAST(get_last_record_timestamp_by_binlog('binlog.000001') AS UNSIGNED) AS raw_ts;
339345
```
340346

341347
=== "Human-Readable Format"
342-
```{.bash}
348+
```sql
343349
SELECT FROM_UNIXTIME(
344350
CAST(get_last_record_timestamp_by_binlog('binlog.000001') AS UNSIGNED) DIV 1000000
345351
) AS last_event_ts;
@@ -370,29 +376,29 @@ Performance issues: These functions read binary log files directly from disk. Fo
370376

371377
Check which binary log files are available:
372378

373-
```{.bash}
379+
```sql
374380
SHOW BINARY LOGS;
375381
```
376382

377383
#### Check GTID status
378384

379385
Verify GTID is enabled:
380386

381-
```{.bash}
387+
```sql
382388
SHOW VARIABLES LIKE 'gtid_mode';
383389
```
384390

385391
### Uninstall the component
386392

387393
Remove the component and all associated functions:
388394

389-
```{.bash}
395+
```sql
390396
UNINSTALL COMPONENT 'file://component_binlog_utils_udf';
391397
```
392398

393-
Verify removal:
399+
Verify removal. Run this command in the MySQL client:
394400

395-
```{.bash}
401+
```sql
396402
SELECT * FROM mysql.component WHERE component_urn = 'file://component_binlog_utils_udf';
397403
```
398404

0 commit comments

Comments
 (0)