database/cutover/verify.sh proves the MySQL → Postgres engine conversion is
lossless on the real application schema. It has never been run. It should pass
before next is fast-forwarded onto main, because at that point the v5 line
becomes what operators upgrade to.
Note: the cutover tooling is named for "v10" throughout (v4-to-v10.load,
RUNBOOK.md, verify.sh) from when that was the working name for this
release. The release is v5. Renaming is tracked separately; the paths below
are the real ones on disk.
Why this is a gate
v5's migrations are Postgres-only: INET columns with ip::inet casts,
jsonb, and partial indexes (CREATE INDEX ... WHERE ...). Staying on MySQL is
not an option, so a v4 operator's data has to be converted by pgloader before
artisan migrate runs. That ordering, and the tooling, are already written up in
database/cutover/RUNBOOK.md. What is missing is evidence that the recipe
actually works.
What to run
bash database/cutover/verify.sh # expect: RESULT: PASS
It is self-contained (seeds a throwaway MySQL, runs the pgloader recipe into a
scratch Postgres DB, asserts per-table COUNT(*) equality plus per-row checks of
the conversion-risky types: tinyint→boolean, bigint, JSON). It never touches dev
data. Needs Docker.
Where to run it
Not on an arm64 Linux host. dimitri/pgloader is published amd64-only and
pgloader is an SBCL binary, so it segfaults under Linux qemu-user emulation. The
script detects this and tells you rather than reporting a false failure. Run it
on:
- an x86_64 host, or
- macOS with Docker Desktop (Rosetta 2 handles it), or
- any host with
PGLOADER_IMAGE pointed at a native-arch pgloader >= 3.6.9
(Debian's packaged 3.6.7~devel dies on MySQL 8.0 collation IDs with
"N fell through ECASE expression")
Done when
Not covered by this
A green verify.sh validates the engine step against the schema, not against
real data. RUNBOOK.md separately asks for a rehearsal on a restored copy of
production before a real cutover. No one has done that, since the maintainer has
no production data — worth tracking separately if a v4 operator can supply a
sanitized dump.
database/cutover/verify.shproves the MySQL → Postgres engine conversion islossless on the real application schema. It has never been run. It should pass
before
nextis fast-forwarded ontomain, because at that point the v5 linebecomes what operators upgrade to.
Why this is a gate
v5's migrations are Postgres-only:
INETcolumns withip::inetcasts,jsonb, and partial indexes (CREATE INDEX ... WHERE ...). Staying on MySQL isnot an option, so a v4 operator's data has to be converted by pgloader before
artisan migrateruns. That ordering, and the tooling, are already written up indatabase/cutover/RUNBOOK.md. What is missing is evidence that the recipeactually works.
What to run
bash database/cutover/verify.sh # expect: RESULT: PASSIt is self-contained (seeds a throwaway MySQL, runs the pgloader recipe into a
scratch Postgres DB, asserts per-table
COUNT(*)equality plus per-row checks ofthe conversion-risky types: tinyint→boolean, bigint, JSON). It never touches dev
data. Needs Docker.
Where to run it
Not on an arm64 Linux host.
dimitri/pgloaderis published amd64-only andpgloader is an SBCL binary, so it segfaults under Linux qemu-user emulation. The
script detects this and tells you rather than reporting a false failure. Run it
on:
PGLOADER_IMAGEpointed at a native-arch pgloader >= 3.6.9(Debian's packaged 3.6.7~devel dies on MySQL 8.0 collation IDs with
"N fell through ECASE expression")
Done when
verify.shreportsRESULT: PASSv4-to-v10.load) or an environment issue (document it in the RUNBOOK)Not covered by this
A green
verify.shvalidates the engine step against the schema, not againstreal data.
RUNBOOK.mdseparately asks for a rehearsal on a restored copy ofproduction before a real cutover. No one has done that, since the maintainer has
no production data — worth tracking separately if a v4 operator can supply a
sanitized dump.