Change Details

For some schema changes, when the altered table is very busy, it is common for the schema change to fail with Duplicate Entry. This has happened on T300402 and the work around was to change the ALTER table to include stop replication before the alter and start it after it has run: `stop slave; ALTER TABLE xxxx; start slave` Ideally we should have a flag on the code to do this nicely, something like: `stop_replication = True` Which would run a `stop slave` before the alter and `start slave` after it.

For some schema changes, when the altered table is very busy, it is common for the schema change to fail with Duplicate Entry. This has happened on T300402 and the work around was to change the ALTER table to include stop replication before the alter and start it after it has run: `stop slave; ALTER TABLE xxxx; start slave` This unfortunately means a stop slave and start slave for all the wikis, which on s3 could be issue 900 times. Ideally we should have a flag on the code to do this nicely, something like: `stop_replication = True` Which would run a `stop slave` before the alter on the first wiki and `start slave` after it the last one is done

For some schema changes, when the altered table is very busy, it is common for the schema change to fail with Duplicate Entry. This has happened on T300402 and the work around was to change the ALTER table to include stop replication before the alter and start it after it has run: `stop slave; ALTER TABLE xxxx; start slave` This unfortunately means a stop slave and start slave for all the wikis, which on s3 could be issue 900 times. Ideally we should have a flag on the code to do this nicely, something like: `stop_replication = True` Which would run a `stop slave` before the alter on the first wiki and `start slave` after it.it the last one is done