You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/cut-over.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,10 +10,10 @@ Another option to support a atomic swap without the use of a lock is the use of
10
10
gh-ost philosophy is avoid the use of triggers but in some environments like a Galera cluster isn't possible use the
11
11
lock command, and like the cut-over should take a little time it shouldn't be a problem. Triggers cut-over works like the following:
12
12
13
-
-gh-ost disable the writes but it keep reading the binlog to keep a record of the changed rows.
13
+
-A stop writes event is injected in the binlog and gh-ost disable the writes once it receive it.
14
14
- The triggers are created to handle the modifications in the MySQL side.
15
15
- A created triggers event is injected in the binlog and gh-ost wait until receive it.
16
-
- The affected rows during the change of writer could be in an inconsistent state, for this reason is necessary sanitize the modified rows removing them if exists and adding them if exists from the original table to the ghost one.
16
+
- The affected rows will be in an inconsistent stata during the time between the first and the second event. For this reason, this events are checked and, the values of the fields that are part of the unique key used to do the online alter are saved to sanitize that rows.
17
17
18
18
`gh-ost` solves this by using an atomic, two-step blocking swap: while one connection holds the lock, another attempts the atomic `RENAME`. The `RENAME` is guaranteed to not be executed prematurely by positioning a sentry table which blocks the `RENAME` operation until `gh-ost` is satisfied all is in order.
0 commit comments