5 ms·
> don't have a sense of scale From [1], complete db is ~300GB and from some iffy pixel measurement of the graph at the very bottom of that page, copying speed
by aexaey 10y ago
> don't have a sense of scale
From [1], complete db is ~300GB and from some iffy pixel measurement of the graph at the very bottom of that page, copying speed between otherwise idle db hosts was about 22.8 GB/hour (in-production replication is probably slower than that).
From that, 4GB of replication lag would represent 1.3% of db by size, or 10+ minutes of lag (as measured by time required to catch up under ideal circumstances).
[1] https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-...
- stock_toaster 10y agoThanks for the context, in my personal experience at jobs dealing with large databases, we always used "minutes behind" to determine how well our replication was keeping up. This was the first I had heard of someone using data size for that same metric.
- johannes1234321 10y agoBoth have different uses. Seconds behind is useful to see how critical this is to the user (they see outdated data), data behind tells you about load and let's you guess how much time is required for catching up
- hyperpape 10y agoI didn't think to eyeball the graph to guesstimate how long the 4GB translated to, so thanks. However, scale was the wrong word for what I was wondering about. My question should've been whether 1% of your total DB/10 minutes of replication lag seems reasonable/nothing to worry about, like the article suggested.
- joking 10y agoIt was an issue, part of the reason that a tired person was working trying to reduce it.