Remove support for MySQL 5.6 (end-of-life Feb 2021)
This commit is contained in:
dm-2
parent
e15166ecb9
commit
f62e9dc4f4
2
.github/workflows/replica-tests.yml
vendored
2
.github/workflows/replica-tests.yml
vendored
|
|
@ -8,7 +8,7 @@ jobs:
|
||||||
runs-on: ubuntu-latest
|
runs-on: ubuntu-latest
|
||||||
strategy:
|
strategy:
|
||||||
matrix:
|
matrix:
|
||||||
version: [mysql-5.6.43,mysql-5.7.25,mysql-8.0.16]
|
version: [mysql-5.7.25,mysql-8.0.16]
|
||||||
|
|
||||||
steps:
|
steps:
|
||||||
- uses: actions/checkout@v2
|
- uses: actions/checkout@v2
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
|
|
||||||
### Requirements
|
### Requirements
|
||||||
|
|
||||||
- `gh-ost` currently requires MySQL versions 5.6 and greater.
|
- `gh-ost` currently requires MySQL versions 5.7 and greater.
|
||||||
|
|
||||||
- You will need to have one server serving Row Based Replication (RBR) format binary logs. Right now `FULL` row image is supported. `MINIMAL` to be supported in the near future. `gh-ost` prefers to work with replicas. You may [still have your master configured with Statement Based Replication](migrating-with-sbr.md) (SBR).
|
- You will need to have one server serving Row Based Replication (RBR) format binary logs. Right now `FULL` row image is supported. `MINIMAL` to be supported in the near future. `gh-ost` prefers to work with replicas. You may [still have your master configured with Statement Based Replication](migrating-with-sbr.md) (SBR).
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -38,7 +38,7 @@ Note that you may dynamically change both `--max-lag-millis` and the `throttle-c
|
||||||
|
|
||||||
`--max-load='Threads_running=100,Threads_connected=500'`
|
`--max-load='Threads_running=100,Threads_connected=500'`
|
||||||
|
|
||||||
Metrics must be valid, numeric [status variables](http://dev.mysql.com/doc/refman/5.6/en/server-status-variables.html)
|
Metrics must be valid, numeric [status variables](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html)
|
||||||
|
|
||||||
#### Throttle query
|
#### Throttle query
|
||||||
|
|
||||||
|
|
@ -97,7 +97,7 @@ Copy: 0/2915 0.0%; Applied: 0; Backlog: 0/100; Elapsed: 42s(copy), 42s(total); s
|
||||||
|
|
||||||
Throttling time is limited by the availability of the binary logs. When throttling begins, `gh-ost` suspends reading the binary logs, and expects to resume reading from same binary log where it paused.
|
Throttling time is limited by the availability of the binary logs. When throttling begins, `gh-ost` suspends reading the binary logs, and expects to resume reading from same binary log where it paused.
|
||||||
|
|
||||||
Your availability of binary logs is typically determined by the [expire_logs_days](https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_expire_logs_days) variable. If you have `expire_logs_days = 10` (or check `select @@global.expire_logs_days`), then you should be able to throttle for up to `10` days.
|
Your availability of binary logs is typically determined by the [expire_logs_days](https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_expire_logs_days) variable. If you have `expire_logs_days = 10` (or check `select @@global.expire_logs_days`), then you should be able to throttle for up to `10` days.
|
||||||
|
|
||||||
Having said that, throttling for so long is far fetching, in that the `gh-ost` process itself must be kept alive during that time; and the amount of binary logs to process once it resumes will potentially take days to replay.
|
Having said that, throttling for so long is far fetching, in that the `gh-ost` process itself must be kept alive during that time; and the amount of binary logs to process once it resumes will potentially take days to replay.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@ Existing MySQL schema migration tools:
|
||||||
- [LHM](https://github.com/soundcloud/lhm)
|
- [LHM](https://github.com/soundcloud/lhm)
|
||||||
- [oak-online-alter-table](https://github.com/shlomi-noach/openarkkit)
|
- [oak-online-alter-table](https://github.com/shlomi-noach/openarkkit)
|
||||||
|
|
||||||
are all using [triggers](http://dev.mysql.com/doc/refman/5.6/en/triggers.html) to propagate live changes on your table onto a ghost/shadow table that is slowly being synchronized. The tools not all work the same: while most use a synchronous approach (all changes applied on the ghost table), the Facebook tool uses an asynchronous approach (changes are appended to a changelog table, later reviewed and applied on ghost table).
|
are all using [triggers](https://dev.mysql.com/doc/refman/5.7/en/triggers.html) to propagate live changes on your table onto a ghost/shadow table that is slowly being synchronized. The tools not all work the same: while most use a synchronous approach (all changes applied on the ghost table), the Facebook tool uses an asynchronous approach (changes are appended to a changelog table, later reviewed and applied on ghost table).
|
||||||
|
|
||||||
Use of triggers simplifies a lot of the flow in doing a live table migration, but also poses some limitations or difficulties. Here are reasons why we choose to [design a triggerless solution](triggerless-design.md) to schema migrations.
|
Use of triggers simplifies a lot of the flow in doing a live table migration, but also poses some limitations or difficulties. Here are reasons why we choose to [design a triggerless solution](triggerless-design.md) to schema migrations.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
(5.6)
|
|
||||||
Loading…
Reference in New Issue
Block a user