Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: TiDB Binlog 该如何理解,有没有必要开启?
【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】6.5
My thinking is fixed on MySQL’s Binlog. How should I understand TiDB’s Binlog? At first glance, they seem different. How does everyone understand it?
TiDB’s binlog is completely different from MySQL’s binlog, and it is no longer recommended to use it.
I understand that they are both logical change logs (as opposed to physical redo logs) and can be used for synchronization and recovery scenarios, but they use different protocols.
In MySQL, both the SQL execution layer and the data storage layer are located on the MySQL node, so MySQL’s binlog can be of SQL type, row type, or mixed type.
In contrast, TiDB’s SQL execution layer is the TiDB-server, and the data storage layer is TiKV. TiDB’s binlog is generated by the TiDB-server, so the binlog is always of SQL type.
TiCDC, which was later introduced in TiDB, targets the TiKV layer and directly captures data changes from TiKV. You can think of this as MySQL’s row-type binlog. This method directly retrieves data changes from the storage layer, offering stronger performance and better consistency guarantees.
The expert explained it very clearly.
If TiDB requires a downstream, then enable binlog.
Nowadays, TiCDC is generally used more often.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.