Skip to content

Commit 736c8a0

Browse files
author
Shlomi Noach
committed
typos
1 parent ad3d1b2 commit 736c8a0

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

doc/subsecond-lag.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -10,11 +10,11 @@ Replication lag is measured on:
1010
- The "inspected" server (the server `gh-ost` connects to; replica is desired but not mandatory)
1111
- The `throttle-control-replicas` list
1212

13-
For the inspected server, `gh-ost` uses an internal heartbeat mechanism. It injects heartbeat events onto the utility changelog table, then reads those events in the binary log, and compares times. This measurement is by default adn by definition sub-second enabled.
13+
For the inspected server, `gh-ost` uses an internal heartbeat mechanism. It injects heartbeat events onto the utility changelog table, then reads those events in the binary log, and compares times. This measurement is by default and by definition sub-second enabled.
1414

1515
You can explicitly define how frequently will `gh-ost` inject heartbeat events, via `heartbeat-interval-millis`. You should set `heartbeat-interval-millis <= max-lag-millis`. It still works if not, but loses granularity and effect.
1616

17-
On the `throttle-control-replicas`, `gh-ost` only issues SQL queries, and does not attempt to read the binary log stream. Perhaps thsoe other replicas don't have binary logs in the first place.
17+
On the `throttle-control-replicas`, `gh-ost` only issues SQL queries, and does not attempt to read the binary log stream. Perhaps those other replicas don't have binary logs in the first place.
1818

1919
The standard way of getting replication lag on a replica is to issue `SHOW SLAVE STATUS`, then reading `Seconds_behind_master` value. But that value has a `1sec` granularity.
2020

0 commit comments

Comments
 (0)