NOTE
4.4 Distributed-System Replication Logs
1. What They Are - Data changes between replicas are generally tracked through replication logs, with several formats. 2. Categories 2.1. Physical Logs - Which page was modified, what was the original value, and what is the updated value. 2.2. Logical Logs - Which record was modified, further divided into Statement and Row.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What They Are
- Data changes between replicas are generally tracked through replication logs, with several formats.
2. Categories
2.1. Physical Logs
- Which page was modified, what was the original value, and what is the updated value.
2.2. Logical Logs
- Which record was modified. They are further divided into Statement and Row.
2.2.1. Statement
- The original statement requested by the client.
- Disadvantage: some statements, such as time functions, can have side effects.
2.2.2. Row
- For row insertion, the log records the new values of the relevant columns.
- For row deletion, the log indicates that this row was deleted.
- For row updates, the log records the new values of all columns.
- Disadvantage: takes up a lot of space. For example, deleting 10,000 rows requires recording that 10,000 rows were deleted.
3. Examples
- MySQL’s server-layer bin-log is a logical log and supports Statement and Row.
- MySQL’s storage-engine-layer redo-log is a physical log.
- Redis uses AOF, which is a logical log.
- Kafka’s log itself is the data.
- ZooKeeper uses?
- Elasticsearch does not use a log; instead, the primary shard sends synchronization requests in parallel to replica shards.
Discussion
Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub