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
{{ message }}
Repository navigation
Commit c050e20
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: Docs/replication/binlog.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,6 +43,8 @@ The contents of binlog files can be inspected in two ways:
43
43
44
44
Unlike in the traditional binlog format, one binlog event can be stored in multiple different binlog files, and different parts of individual events can be interleaved with one another in each file. The `mariadb-binlog` program will coalesce the different parts of each event as necessary, so the output of the program is a consistent, non-interleaved stream of events. To obtain a correct seequnce of events across multiple binlog files, all binlog files should be passed to the `mariadb-binlog` program at once in correct order; this ensures that events that cross file boundaries are included in the output exactly once.
45
45
46
+
Note that with `--binlog-storage-engine=innodb`, binlog files are written to disk in the background. There will be some delay from the time a transaction is committed until the data gets written to the binlog file, more so for the last page of data which is only written when it gets full or when InnoDB performs a checkpoint. The server makes the data available quickly to slaves and to `mariadb-binlog --read-from-remote-server` by reading from in-memory buffers, and the data is always written immediately to the InnoDB redo log and will be recovered correctly in case of a crash; the delayed writing to the binlog files themselves is purely a performance optimization. The `FLUSH BINARY LOGS` command can be used to force the writing of all current binlog data into the binlog files.
47
+
46
48
When using the `--start-position` and `--stop-position` options of `mariadb-binlog`, it is recommended to use GTID positions. The event file offsets used in the tranditional binlog format are not used in the new binlog, and will mostly be reported as zero.
47
49
48
50
The `--binlog-checksum` option is no longer used with the new binlog implementation. The binlog files are always checksummed, with a CRC32 at the end of each page. To have checksum of the data sent on the network between the master and the slave (in addition to the normal TCP checksums), use the `MASTER_SSL` option for `CHANGE MASTER` to make the connection use SSL.
0 commit comments