Skip to content

Commit 8914bc2

Browse files
author
Shlomi Noach
authored
Merge pull request #366 from github/doc-questions
Documentation: common questions
2 parents 5af7026 + e021f43 commit 8914bc2

2 files changed

Lines changed: 28 additions & 1 deletion

File tree

README.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -58,9 +58,10 @@ More tips:
5858
Also see:
5959

6060
- [requirements and limitations](doc/requirements-and-limitations.md)
61+
- [common questions](doc/questions.md)
6162
- [what if?](doc/what-if.md)
6263
- [the fine print](doc/the-fine-print.md)
63-
- [Questions](https://github.com/github/gh-ost/issues?q=label%3Aquestion)
64+
- [Community questions](https://github.com/github/gh-ost/issues?q=label%3Aquestion)
6465

6566
## What's in a name?
6667

doc/questions.md

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
# How?
2+
3+
### How does the cut-over work? Is it really atomic?
4+
5+
The cut-over phase, where the original table is swapped away, and the _ghost_ table takes its place, is an atomic, blocking, controlled operation.
6+
7+
- Atomic: the tables are swapped together. There is no gap where your table does not exist.
8+
- Blocking: all app queries involving the migrated (original) table are either operate on the original table, or are blocked, or proceed to operate on the _new_ table (formerly the _ghost_ table, now swapped in).
9+
- Controlled: the cut-over times out at pre-defined threshold, and is atomically aborted, then re-attempted. Cut-over only takes place when no lags are present, and otherwise no throttling reason is found. Cut-over step itself gets high priority and is never throttled.
10+
11+
Read more on [cut-over](cut-over.md) and on the [cut-over design Issue](https://github.com/github/gh-ost/issues/82)
12+
13+
14+
# Is it possible to?
15+
16+
### Is it possible to add a UNIQUE KEY?
17+
18+
Adding a `UNIQUE KEY` is possible, in the condition that no violation will occur. That is, you must make sure there aren't any violating rows on your table before, and during the migration.
19+
20+
At this time there is no equivalent to `ALTER IGNORE`, where duplicates are implicitly and silently thrown away. The MySQL `5.7` docs say:
21+
22+
> As of MySQL 5.7.4, the IGNORE clause for ALTER TABLE is removed and its use produces an error.
23+
24+
It is therefore unlikely that `gh-ost` will support this behavior.
25+
26+
# Why

0 commit comments

Comments
 (0)