Merge pull request #120 from github/the-fine-print
adding The Fine Print documentation
This commit is contained in:
Shlomi Noach
GitHub
commit
f11a39fb2a
1
.github/PULL_REQUEST_TEMPLATE.md
vendored
1
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -6,6 +6,7 @@
|
||||
|
||||
Related issue: https://github.com/github/gh-ost/issues/0123456789
|
||||
|
||||
> Further notes in https://github.com/github/gh-ost/blob/master/.github/CONTRIBUTING.md
|
||||
> Thank you! We are open to PRs, but please understand if for technical reasons we are unable to accept each and any PR
|
||||
|
||||
### Description
|
||||
|
||||
11
README.md
11
README.md
@ -30,7 +30,7 @@ In addition, it offers many [operational perks](doc/perks.md) that make it safer
|
||||
- Auditing: you may query `gh-ost` for status. `gh-ost` listens on unix socket or TCP.
|
||||
- Control over cut-over phase: `gh-ost` can be instructed to postpone what is probably the most critical step: the swap of tables, until such time that you're comfortably available. No need to worry about ETA being outside office hours.
|
||||
|
||||
Please meanwhile refer to the [docs](doc) for more information. No, really, read the [docs](doc).
|
||||
Please refer to the [docs](doc) for more information. No, really, read the [docs](doc).
|
||||
|
||||
## Usage
|
||||
|
||||
@ -54,14 +54,17 @@ More tips:
|
||||
- Use `--postpone-cut-over-flag-file` to gain control over cut-over timing
|
||||
- Get familiar with the [interactive commands](doc/interactive-commands.md)
|
||||
|
||||
Also see [requirements and limitations](doc/requirements-and-limitations.md), [what if?](doc/what-if.md)
|
||||
Also see:
|
||||
|
||||
- [requirements and limitations](doc/requirements-and-limitations.md)
|
||||
- [what if?](doc/what-if.md)
|
||||
- [the fine print](doc/the-fine-print.md)
|
||||
|
||||
## What's in a name?
|
||||
|
||||
Originally this was named `gh-osc`: GitHub Online Schema Change, in the likes of [Facebook online schema change](https://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932/) and [pt-online-schema-change](https://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html).
|
||||
|
||||
But then a rare genetic mutation happened, and the `s` transformed into `t`. And that sent us down the path of trying to figure out a new acronym. Right now, `gh-ost` (pronounce: _Ghost_), stands for:
|
||||
- GitHub Online Schema Transmogrifier/Translator/Transformer/Transfigurator
|
||||
But then a rare genetic mutation happened, and the `s` transformed into `t`. And that sent us down the path of trying to figure out a new acronym. `gh-ost` (pronounce: _Ghost_), stands for GitHub's Online Schema Transmogrifier/Translator/Transformer/Transfigurator
|
||||
|
||||
## License
|
||||
|
||||
|
||||
@ -12,7 +12,8 @@
|
||||
### Limitations
|
||||
|
||||
- Foreign keys not supported. They may be supported in the future, to some extent.
|
||||
- Triggers are not supported. they may be supported in the future.
|
||||
- Triggers are not supported. They may be supported in the future.
|
||||
- MySQL 5.7 generated columns are not supported. They may be supported in the future.
|
||||
- The two _before_ & _after_ tables must share some `UNIQUE KEY`. Such key would be used by `gh-ost` to iterate the table.
|
||||
- As an example, if your table has a single `UNIQUE KEY` and no `PRIMARY KEY`, and you wish to replace it with a `PRIMARY KEY`, you will need two migrations: one to add the `PRIMARY KEY` (this migration will use the existing `UNIQUE KEY`), another to drop the now redundant `UNIQUE KEY` (this migration will use the `PRIMARY KEY`).
|
||||
- The chosen migration key must not include columns with `NULL` values.
|
||||
|
||||
41
doc/the-fine-print.md
Normal file
41
doc/the-fine-print.md
Normal file
@ -0,0 +1,41 @@
|
||||
# The Fine Print: What are You Not Telling Me?
|
||||
|
||||
Here are technical considerations you may be interested in. We write here things that are not an obvious [Requirements & Limitations](requirements-and-limitations.md)
|
||||
|
||||
# Connecting to replica
|
||||
|
||||
`gh-ost` prefers connecting to replica. If your master uses Statement Based Replication, this is a _requirement_.
|
||||
|
||||
What does "connect to replica" mean?
|
||||
|
||||
- `gh-ost` connects to the replica as a normal client
|
||||
- It additionally connects as a replica to the replica (pretends to be a MySQL replica itself)
|
||||
- It auto-detects master
|
||||
|
||||
`gh-ost` reads the RBR binary logs from the replica, and applies events onto the master as tables are being migrated.
|
||||
|
||||
THE FINE PRINT:
|
||||
|
||||
- You trust the replica's binary logs to represent events applied on master.
|
||||
If you don't trust the replica, if you suspect there's data drift between replica & master, take notice. If your master is RBR, do instead connect `gh-ost` to master, via `--allow-on-master` (see [cheatsheet](cheatsheet.md)).
|
||||
Our take: we trust replica data; if master dies in production, we promote a replica. Our read serving is based on replica(s).
|
||||
|
||||
- Replication needs to run.
|
||||
This is an obvious, but worth stating. You cannot perform a migration with "connect to replica" if your replica lags. `gh-ost` will actually do all it can so that replication does not lag, and avoid critical operations at such time when replication does lag.
|
||||
|
||||
# Network usage
|
||||
|
||||
`gh-ost` reads binary logs and then applies them onto the migrated server.
|
||||
|
||||
THE FINE PRINT:
|
||||
|
||||
- `gh-ost` delivers more network traffic than other online-schema-change tools, that let MySQL handle all data transfer internally. This is part of the [triggerless design](triggerless-design.md).
|
||||
Our take: we deal with cross-DC migration traffic and this is working well for us.
|
||||
|
||||
# Impersonating as a replica
|
||||
|
||||
`gh-ost` impersonates as a replica: connects to a MySQL server, says "oh hey, I'm a replica, please send me binary logs kthx".
|
||||
|
||||
THE FINE PRINT:
|
||||
|
||||
- `SHOW SLAVE HOSTS` or `SHOW PROCESSLIST` will list down this strange "replica" that you can't really connect to.
|
||||
@ -44,105 +44,81 @@ Those are relatively self explanatory. Mostly they indicate that all goes well.
|
||||
You will be mostly interested in following up on the migration and understanding whether it goes well. Once migration actually begins, you will see output as follows:
|
||||
|
||||
```
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 0/100; Elapsed: 0s(copy), 6s(total); streamer: mysql-bin.002587:348727198; ETA: N/A
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 1s(copy), 7s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=83.000000s
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 2s(copy), 8s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=79.000000s
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 3s(copy), 9s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=74.000000s
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 4s(copy), 10s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=69.000000s
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 5s(copy), 11s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=65.000000s
|
||||
Copy: 0/752865 0.0%; Applied: 0; Backlog: 0/100; Time: 29s(total), 0s(copy); streamer: mysql-bin.007068:846528615; ETA: N/A
|
||||
Copy: 0/752865 0.0%; Applied: 0; Backlog: 0/100; Time: 30s(total), 1s(copy); streamer: mysql-bin.007068:846875570; ETA: N/A
|
||||
Copy: 7300/752865 1.0%; Applied: 0; Backlog: 0/100; Time: 31s(total), 2s(copy); streamer: mysql-bin.007068:855439063; ETA: N/A
|
||||
Copy: 14100/752865 1.9%; Applied: 0; Backlog: 0/100; Time: 32s(total), 3s(copy); streamer: mysql-bin.007068:864722759; ETA: 2m37s
|
||||
Copy: 20100/752865 2.7%; Applied: 0; Backlog: 0/100; Time: 33s(total), 4s(copy); streamer: mysql-bin.007068:874346340; ETA: 2m26s
|
||||
Copy: 27000/752865 3.6%; Applied: 0; Backlog: 0/100; Time: 34s(total), 5s(copy); streamer: mysql-bin.007068:886997306; ETA: 2m14s
|
||||
...
|
||||
```
|
||||
In the above we're mostly interested to see that `ETA: throttled, replica-lag=65.000000s`.
|
||||
|
||||
- Migration is throttled, i.e. `gh-ost` finds that the server is too busy, or replication is too far behind, and so it ceases (or does not start) data copy operation.
|
||||
- It also provides a reason for the throttling. In out case it seems replication is too far behind. `gh-ost` awaits until replication lag is smaller than `--max-lag-millis`.
|
||||
|
||||
However another thing catches the eye: `Backlog: 0/100` transitions into `Backlog: 100/100`
|
||||
|
||||
- `Backlog` is the binlog events queue. A queue of events read from the binary log which are relevant for the migration. The queue gets emptied as events are applied onto the ghost table. Typically we want to see that queue empty or almost empty. However, due to the fact we're not throttled it makes perfect sense that the queue is full: throttling means we do not apply events onto the ghost table, hence we do not purge the queue.
|
||||
In the above some time was spent on counting table rows. `29s` have elapsed before actual rowcopy began. `gh-ost` will not deliver ETA before `1%` of the copy is complete.
|
||||
|
||||
```
|
||||
...
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 16s(copy), 22s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=8.000000s
|
||||
Copy: 0/4466810 0.0%; Applied: 0; Backlog: 100/100; Elapsed: 17s(copy), 23s(total); streamer: mysql-bin.002587:349815124; ETA: throttled, replica-lag=2.000000s
|
||||
Copy: 0/4466885 0.0%; Applied: 1492; Backlog: 100/100; Elapsed: 18s(copy), 24s(total); streamer: mysql-bin.002587:358722182; ETA: N/A
|
||||
Copy: 0/4466942 0.0%; Applied: 2966; Backlog: 100/100; Elapsed: 19s(copy), 25s(total); streamer: mysql-bin.002587:367190999; ETA: N/A
|
||||
Copy: 0/4466993 0.0%; Applied: 4462; Backlog: 1/100; Elapsed: 20s(copy), 26s(total); streamer: mysql-bin.002587:376732190; ETA: N/A
|
||||
Copy: 12500/4466994 0.3%; Applied: 4496; Backlog: 2/100; Elapsed: 21s(copy), 27s(total); streamer: mysql-bin.002587:381475469; ETA: N/A
|
||||
Copy: 25000/4466997 0.6%; Applied: 4535; Backlog: 6/100; Elapsed: 22s(copy), 28s(total); streamer: mysql-bin.002587:386747649; ETA: N/A
|
||||
Copy: 40000/4467001 0.9%; Applied: 4582; Backlog: 3/100; Elapsed: 23s(copy), 29s(total); streamer: mysql-bin.002587:393017028; ETA: N/A
|
||||
Copy: 460900/752865 61.2%; Applied: 0; Backlog: 0/100; Time: 2m35s(total), 2m6s(copy); streamer: mysql-bin.007069:596112173; ETA: 1m19s
|
||||
Copy: 466600/752865 62.0%; Applied: 0; Backlog: 0/100; Time: 2m40s(total), 2m11s(copy); streamer: mysql-bin.007069:622646704; ETA: throttled, my.replica-01.com:3306 replica-lag=3.000000s
|
||||
Copy: 478500/752865 63.6%; Applied: 0; Backlog: 0/100; Time: 2m45s(total), 2m16s(copy); streamer: mysql-bin.007069:641258880; ETA: 1m17s
|
||||
Copy: 496900/752865 66.0%; Applied: 0; Backlog: 0/100; Time: 2m50s(total), 2m21s(copy); streamer: mysql-bin.007069:678956577; ETA: throttled, my.replica-01.com:3306 replica-lag=2.000000s
|
||||
Copy: 496900/752865 66.0%; Applied: 0; Backlog: 0/100; Time: 2m55s(total), 2m26s(copy); streamer: mysql-bin.007069:681610879; ETA: throttled, max-load Threads_running=26 >= 25
|
||||
Copy: 528000/752865 70.1%; Applied: 0; Backlog: 0/100; Time: 3m0s(total), 2m31s(copy); streamer: mysql-bin.007069:711177703; ETA: throttled, lag=2.483039s
|
||||
Copy: 564900/752865 75.0%; Applied: 0; Backlog: 0/100; Time: 3m30s(total), 3m1s(copy); streamer: mysql-bin.007069:795150744; ETA: throttled, lag=3.482914s
|
||||
Copy: 577200/752865 76.7%; Applied: 0; Backlog: 0/100; Time: 3m39s(total), 3m10s(copy); streamer: mysql-bin.007069:819956052; ETA: 57s
|
||||
Copy: 589300/752865 78.3%; Applied: 0; Backlog: 0/100; Time: 3m56s(total), 3m27s(copy); streamer: mysql-bin.007069:858738375; ETA: 57s
|
||||
Copy: 595700/752865 79.1%; Applied: 0; Backlog: 0/100; Time: 3m57s(total), 3m28s(copy); streamer: mysql-bin.007069:860745762; ETA: 54s
|
||||
```
|
||||
|
||||
In the above, `gh-ost` found replication to be caught up and began operation. We note:
|
||||
- `Backlog` goes down to `1` or `2` or otherwise smaller numbers. This means we are good with processing the binlog events and applying them onto the ghost table.
|
||||
- `Applied` is the incrementing number of events we have applied from the binary log onto the ghost table, since the migration began.
|
||||
- `Copy`: at the beginning the tool estimated `4466810` rows already existing in the table. Initially `0` of them are copied, hence `0/4466810`. But as `gh-ost` makes progress, this number grows:
|
||||
- `12500/4466994 0.3%`
|
||||
- `25000/4466997 0.6%`
|
||||
- `40000/4467001 0.9%`
|
||||
- You can also observe that the number of rows changes. This is implied by the flag `--exact-rowcount`, where we try and keep an updated amount of rows were are going to process throughout the migration, even as new rows are added and old rows deleted. This is not an exact number, but turns out to be a pretty good estimate.
|
||||
- `Elapsed: 23s(copy), 29s(total)`: `total` stands for total time from executing of `gh-ost`. `copy` stands for the time elapsed since `gh-ost` finished making preparations and was good to go with copy.
|
||||
- `streamer: mysql-bin.002587:393017028` tells us which binary log entry is `gh-ost` processing at this time.
|
||||
- `ETA`: Estimated Time of Arrival, is still `N/A` since `gh-ost` has not collected enough data to make an estimate.
|
||||
In the above migration is throttled on occasion.
|
||||
|
||||
Some time later, we will have:
|
||||
- A few times because one of the control replicas, specifically `my.replica-01.com:3306`, was lagging
|
||||
- Once because `max-load` threshold has been reached (`Threads_running=26 >= 25`)
|
||||
- Once because the migration replica itself (the server into which `gh-ost` connected) lagged.
|
||||
|
||||
`gh-ost` will always specify the reason for throttling.
|
||||
|
||||
### Progress
|
||||
|
||||
- `Copy: 595700/752865 79.1%` indicates the number of existing table rows copied onto the _ghost_ table, out of an estimate of the total row count.
|
||||
- `Applied: 0` indicates the number of entries processed in the binary log and applied onto the _ghost_ table. In the examples above there was no traffic on the migrated table, hence no rows processed.
|
||||
|
||||
A migration on a more intensively used table may look like this:
|
||||
|
||||
```
|
||||
Copy: 50000/4467001 1.1%; Applied: 4620; Backlog: 6/100; Elapsed: 24s(copy), 30s(total); streamer: mysql-bin.002587:396414283; ETA: 35m20s
|
||||
Copy: 62500/4467002 1.4%; Applied: 4671; Backlog: 3/100; Elapsed: 25s(copy), 31s(total); streamer: mysql-bin.002587:402582372; ETA: 29m21s
|
||||
Copy: 75000/4467003 1.7%; Applied: 4703; Backlog: 3/100; Elapsed: 26s(copy), 32s(total); streamer: mysql-bin.002587:407864888; ETA: 25m22s
|
||||
Copy: 87500/4467004 2.0%; Applied: 4751; Backlog: 6/100; Elapsed: 27s(copy), 33s(total); streamer: mysql-bin.002587:413142992; ETA: 22m31s
|
||||
Copy: 100000/4467004 2.2%; Applied: 4795; Backlog: 6/100; Elapsed: 28s(copy), 34s(total); streamer: mysql-bin.002587:418380729; ETA: 20m22s
|
||||
Copy: 112500/4467005 2.5%; Applied: 4835; Backlog: 1/100; Elapsed: 29s(copy), 35s(total); streamer: mysql-bin.002587:423592450; ETA: 18m42s
|
||||
Copy: 30713100/43138319 71.2%; Applied: 381910; Backlog: 0/100; Time: 2h6m30s(total), 2h3m20s(copy); streamer: mysql-bin.006792:1001340307; ETA: 49m53s
|
||||
Copy: 30852500/43138338 71.5%; Applied: 383365; Backlog: 0/100; Time: 2h7m0s(total), 2h3m50s(copy); streamer: mysql-bin.006792:1050191186; ETA: 49m18s
|
||||
2016-07-25 03:20:41 INFO rotate to next log name: mysql-bin.006793
|
||||
2016-07-25 03:20:41 INFO rotate to next log name: mysql-bin.006793
|
||||
Copy: 30925700/43138360 71.7%; Applied: 384873; Backlog: 0/100; Time: 2h7m30s(total), 2h4m20s(copy); streamer: mysql-bin.006793:9144080; ETA: 49m5s
|
||||
Copy: 31028800/43138380 71.9%; Applied: 386325; Backlog: 0/100; Time: 2h8m0s(total), 2h4m50s(copy); streamer: mysql-bin.006793:47984430; ETA: 48m43s
|
||||
Copy: 31165600/43138397 72.2%; Applied: 387787; Backlog: 0/100; Time: 2h8m30s(total), 2h5m20s(copy); streamer: mysql-bin.006793:96139474; ETA: 48m8s
|
||||
Copy: 31291200/43138418 72.5%; Applied: 389257; Backlog: 7/100; Time: 2h9m0s(total), 2h5m50s(copy); streamer: mysql-bin.006793:141094700; ETA: 47m38s
|
||||
Copy: 31389700/43138432 72.8%; Applied: 390629; Backlog: 100/100; Time: 2h9m30s(total), 2h6m20s(copy); streamer: mysql-bin.006793:179473435; ETA: throttled, lag=1.548707s
|
||||
```
|
||||
And `gh-ost` progressively provides an ETA.
|
||||
|
||||
Status frequency:
|
||||
- In the first `60` seconds `gh-ost` emits a status entry every `1` second.
|
||||
- Then, up till `3` minutes into operation, status shows every `5` seconds.
|
||||
- It then drops down to once per `30` seconds
|
||||
- But goes into once-per-`5`-seconds again when it estimates < `3` minutes ETA
|
||||
- And once per `1` second when it estimates < `1` minute ETA
|
||||
Notes:
|
||||
|
||||
```
|
||||
Copy: 602500/4467053 13.5%; Applied: 6770; Backlog: 0/100; Elapsed: 1m14s(copy), 1m20s(total); streamer: mysql-bin.002587:630949369; ETA: 7m54s
|
||||
Copy: 655000/4467060 14.7%; Applied: 6985; Backlog: 6/100; Elapsed: 1m19s(copy), 1m25s(total); streamer: mysql-bin.002587:652696032; ETA: 7m39s
|
||||
Copy: 707500/4467066 15.8%; Applied: 7207; Backlog: 0/100; Elapsed: 1m24s(copy), 1m30s(total); streamer: mysql-bin.002587:674577141; ETA: 7m26s
|
||||
...
|
||||
Copy: 1975000/4466798 44.2%; Applied: 12919; Backlog: 2/100; Elapsed: 3m24s(copy), 3m30s(total); streamer: mysql-bin.002588:119901391; ETA: 4m17s
|
||||
Copy: 2285000/4466855 51.2%; Applied: 14234; Backlog: 13/100; Elapsed: 3m54s(copy), 4m0s(total); streamer: mysql-bin.002588:243346615; ETA: 3m43s
|
||||
...
|
||||
Copy: 4397500/4467226 98.4%; Applied: 22996; Backlog: 8/100; Elapsed: 7m11s(copy), 7m17s(total); streamer: mysql-bin.002588:1063945589; ETA: 6s
|
||||
Copy: 4410000/4467227 98.7%; Applied: 23045; Backlog: 5/100; Elapsed: 7m12s(copy), 7m18s(total); streamer: mysql-bin.002588:1068763841; ETA: 5s
|
||||
Copy: 4420000/4467229 98.9%; Applied: 23086; Backlog: 5/100; Elapsed: 7m13s(copy), 7m19s(total); streamer: mysql-bin.002588:1072751966; ETA: 4s
|
||||
2016-05-19 18:04:25 INFO rotate to next log name: mysql-bin.002589
|
||||
2016-05-19 18:04:25 INFO rotate to next log name: mysql-bin.002589
|
||||
Copy: 4430000/4467231 99.2%; Applied: 23124; Backlog: 3/100; Elapsed: 7m14s(copy), 7m20s(total); streamer: mysql-bin.002589:2944139; ETA: 3s
|
||||
Copy: 4442500/4467231 99.4%; Applied: 23181; Backlog: 2/100; Elapsed: 7m15s(copy), 7m21s(total); streamer: mysql-bin.002589:8042490; ETA: 2s
|
||||
Copy: 4452500/4467232 99.7%; Applied: 23235; Backlog: 5/100; Elapsed: 7m16s(copy), 7m22s(total); streamer: mysql-bin.002589:12084190; ETA: 1s
|
||||
Copy: 4462500/4467235 99.9%; Applied: 23295; Backlog: 8/100; Elapsed: 7m17s(copy), 7m23s(total); streamer: mysql-bin.002589:16174016; ETA: 0s
|
||||
2016-05-19 18:04:29 INFO Row copy complete
|
||||
Copy: 4466492/4467235 100.0%; Applied: 23309; Backlog: 0/100; Elapsed: 7m17s(copy), 7m24s(total); streamer: mysql-bin.002589:17255091; ETA: 0s
|
||||
2016-05-19 18:04:29 INFO Stopping replication
|
||||
2016-05-19 18:04:29 INFO Replication stopped
|
||||
2016-05-19 18:04:29 INFO Verifying SQL thread is running
|
||||
2016-05-19 18:04:29 INFO SQL thread started
|
||||
2016-05-19 18:04:29 INFO Replication IO thread at mysql-bin.001801:719204179. SQL thread is at mysql-bin.001801:719204179
|
||||
2016-05-19 18:04:29 INFO Writing changelog state: AllEventsUpToLockProcessed
|
||||
2016-05-19 18:04:29 INFO Waiting for events up to lock
|
||||
Copy: 4466492/4467235 100.0%; Applied: 23309; Backlog: 1/100; Elapsed: 7m18s(copy), 7m24s(total); streamer: mysql-bin.002589:17702369; ETA: 0s
|
||||
2016-05-19 18:04:30 INFO Done waiting for events up to lock
|
||||
Copy: 4466492/4467235 100.0%; Applied: 23309; Backlog: 0/100; Elapsed: 7m18s(copy), 7m25s(total); streamer: mysql-bin.002589:17703056; ETA: 0s
|
||||
```
|
||||
This migration - insofar - took `7m25s`, has applied `23309` events from the binary log and has copied `4466492` rows onto the ghost table.
|
||||
- `Applied: 381910`: `381910` events in the binary logs presenting changes to the migrated table have been processed and applied on the _ghost_ table since beginning of migration.
|
||||
- `Backlog: 0/100`: we are performing well on reading the binary log. There's nothing known in the binary log queue that awaits processing.
|
||||
- `Backlog: 7/100`: while copying rows, a few events have piled up in the binary log _modifying our table_ that we spotted, and still need to apply.
|
||||
- `Backlog: 100/100`: our buffer of `100` events is full; you may see this during or right after throttling (the binary logs keep filling up with relevant queries that are not being processed), or immediately following a high workload.
|
||||
`gh-ost` will always prioritize binlog event processing (backlog) over row-copy; when next possible (throttling completes, in our example), `gh-ost` will drain the queue first, and only then proceed to resume row copy.
|
||||
There is nothing wrong with seeing `100/100`; it just indicates we're behind at that point in time.
|
||||
- `Copy: 31291200/43138418`, `Copy: 31389700/43138432`: this migration executed with `--exact-rowcount`. `gh-ost` continuously heuristically updates the total number of expected row copies as migration proceeds, hence the change from `43138418` to `43138432`
|
||||
- `streamer: mysql-bin.006793:179473435` tells us which binary log entry is `gh-ost` processing at this time.
|
||||
|
||||
## Status hint
|
||||
### Status hint
|
||||
|
||||
In addition, once every `10` minutes, a friendly reminder is printed, in the following form:
|
||||
|
||||
```
|
||||
# Migrating `mydb`.`mytable`; Ghost table is `mydb`.`_mytable_gst`
|
||||
# Migration started at Mon Jun 06 03:45:08 -0700 2016
|
||||
# chunk-size: 2500; max lag: 1500ms; max-load: map[Threads_connected:30]
|
||||
# Throttle additional flag file: /tmp/gh-ost.throttle
|
||||
# Migrating mysql.master-01.com:3306; inspecting mysql.replica-05.com:3306; executing on some.host-17.com
|
||||
# Migration started at Mon Jul 25 01:13:19 2016
|
||||
# chunk-size: 500; max lag: 1000ms; max-load: Threads_running=25; critical-load: Threads_running=1000; nice-ratio: 0
|
||||
# throttle-additional-flag-file: /tmp/gh-ost.throttle.flag.file
|
||||
# postpone-cut-over-flag-file: /tmp/gh-ost.postpone.flag.file [set]
|
||||
# panic-flag-file: /tmp/gh-ost.panic.flag.file
|
||||
# Serving on unix socket: /tmp/gh-ost.mydb.mytable.sock
|
||||
```
|
||||
|
||||
- The above mostly print out the current configuration. Remember you can [dynamically control](interactive-commands.md) most of them.
|
||||
- `gh-ost` notes that the `postpone-cut-over-flag-file` file actually exists by printing `[set]`
|
||||
|
||||
Loading…
Reference in New Issue
Block a user