-
Notifications
You must be signed in to change notification settings - Fork 422
Conversation
7f25326
to
caabc27
Compare
7a6af20
to
bfa59f7
Compare
$(MAKE) dev.wait-for.mysql57+mysql80 | ||
docker compose exec -T mysql80 mysql -uroot mysql < provision-mysql80.sql | ||
$(MAKE) $(_db_copy8_targets) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The copying is now failing for me, with the following error:
docker compose exec mysql57 mysqldump "credentials" > .dev/credentials.sql
docker compose exec -T mysql80 mysql "credentials" < .dev/credentials.sql
ERROR 2013 (HY000) at line 621: Lost connection to MySQL server during query
make[1]: *** [Makefile:481: dev.dbcopy8.credentials] Error 1
If I dump the logs just before this statement runs, I get a line about "Temporary server started." This temporary server is started and then stopped before the regular mysql server runs. I don't see this in the mysql57 logs. This might mean that mysql80 needs a different availability check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I move the sleep 10
to below the wait-for line, it works. Something is still very strange here, because I can run various checks against MySQL immediately between the provision-mysql80.sql and _db_copy8_targets lines and they always pass, even when run repeatedly in short succession.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I think I've got it! The problem is that the mysql command is talking to the temporary server over a UNIX socket. The solution seems to be to tell mysql to use TCP. I'll submit a separate PR for that, though.
Co-authored-by: Tim McCormack <tmccormack@edx.org>
285c4b6
to
f3c72cd
Compare
Closing this to re-run |
* chore: update dbcopyall8 command
The previous
dbcoopyall8
command causingoperational errors
The occurrence of the
operational errors: table already exists issue
can be traced to the following:provisioning
process, themysql80 container
is populated with themost recent data
, (new migrations/tables).data is transferred
frommysql57
usingdbcopyall8
command, thenewly created tables persist
in the mysql80 container. But, thedjango_migrations
table becomesoutdated
in this process.records
for any new migrationare removed
from thedjango_migrations
table. This leads to a failure when attempting to execute dev.migrate.This PR is to fix the above-mentioned issue.
It will wipe out all the data of
mysql8
before actually dumpingmysql57
data insidemysql80
container.