From d6347c4f33500c35c29ec83fc2edfcf45845f9ef Mon Sep 17 00:00:00 2001 From: Shlomi Noach Date: Sun, 5 Feb 2017 08:03:28 +0200 Subject: [PATCH 1/4] adding common-questions doc page --- doc/questions.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/questions.md diff --git a/doc/questions.md b/doc/questions.md new file mode 100644 index 0000000..33757e5 --- /dev/null +++ b/doc/questions.md @@ -0,0 +1,22 @@ +# How? + +### How does the cut-over work? Is it really atomic? + +The cut-over phase, where the original table is swapped away, and the _ghost_ table takes its place, is an atomic, blocking, controlled operation. + +- Atomic: the tables are swapped together. There is no gap where your table does not exist. +- 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). +- 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. + +Read more on [cut-over](cut-over.md) and on the [cut-over design Issue](https://github.com/github/gh-ost/issues/82) + + +# Is it possible to? + +### Is it possible to add a UNIQUE KEY? + +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. + +At this time there is no equivalent to `ALETER IGNORE`, where duplicates are implicitly and silently thrown away. This behavior may be supported in the future. + +# Why From ad7b700bd8d82aa74d22080531ce3733e4815ff9 Mon Sep 17 00:00:00 2001 From: Shlomi Noach Date: Sun, 5 Feb 2017 08:05:10 +0200 Subject: [PATCH 2/4] link to questions page --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 451b5b2..f312d2f 100644 --- a/README.md +++ b/README.md @@ -58,9 +58,10 @@ More tips: Also see: - [requirements and limitations](doc/requirements-and-limitations.md) +- [common questions](doc/questions.md) - [what if?](doc/what-if.md) - [the fine print](doc/the-fine-print.md) -- [Questions](https://github.com/github/gh-ost/issues?q=label%3Aquestion) +- [Community questions](https://github.com/github/gh-ost/issues?q=label%3Aquestion) ## What's in a name? From 6a468c4f365300637be3002fb9a21be7a83581f9 Mon Sep 17 00:00:00 2001 From: Gillian Gunson Date: Sun, 5 Feb 2017 17:28:22 -0800 Subject: [PATCH 3/4] Fixed tiny typo --- doc/questions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/questions.md b/doc/questions.md index 33757e5..7f9cb20 100644 --- a/doc/questions.md +++ b/doc/questions.md @@ -17,6 +17,6 @@ Read more on [cut-over](cut-over.md) and on the [cut-over design Issue](https:// 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. -At this time there is no equivalent to `ALETER IGNORE`, where duplicates are implicitly and silently thrown away. This behavior may be supported in the future. +At this time there is no equivalent to `ALTER IGNORE`, where duplicates are implicitly and silently thrown away. This behavior may be supported in the future. # Why From ebf7844e373d1ca136b32dd32dc7f3ea85bdfaad Mon Sep 17 00:00:00 2001 From: Shlomi Noach Date: Mon, 6 Feb 2017 07:48:48 +0200 Subject: [PATCH 4/4] 5.7 deprecation of alter ignore --- doc/questions.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/questions.md b/doc/questions.md index 33757e5..f4788f1 100644 --- a/doc/questions.md +++ b/doc/questions.md @@ -17,6 +17,10 @@ Read more on [cut-over](cut-over.md) and on the [cut-over design Issue](https:// 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. -At this time there is no equivalent to `ALETER IGNORE`, where duplicates are implicitly and silently thrown away. This behavior may be supported in the future. +At this time there is no equivalent to `ALETER IGNORE`, where duplicates are implicitly and silently thrown away. The MySQL `5.7` docs say: + +> As of MySQL 5.7.4, the IGNORE clause for ALTER TABLE is removed and its use produces an error. + +It is therefore unlikely that `gh-ost` will support this behavior. # Why