- Set MediaWiki to read content meta-data from the new content table.
Set MediaWiki to not populate the ar_text and ar_flags fields.(this has been the case since MW 1.5)
- Watch for performance issues caused by adding a level of indirection (a JOIN) to revision loads.
- Set MediaWiki to insert content meta-data ONLY into the new columns in the content table. (To allow this, the old columns must have a DEFAULT).
- Enable MCR support in the API and UI (as far as implemented).
- Optional: Drop the redundant columns from the page, revision, and archive tables, see Removing Redundant Information above. Schema changes desired for revision storage optimization may be applied at the same time.
|· · ·|
|Open||None||T183490 MCR schema migration stage 4: Migrate External Store URLs (wmf production)|
|Open||None||T183487 MCR schema migration stage 3: drop support for legacy fields (wmf production)|
|Resolved||tstarling||T183488 MCR schema migration stage 2: populate new fields|
|Open||None||T198312 Set the WMF cluster to use the new MCR-only schema|
|Open||BPirkle||T198341 Remove all references to the rev_text_id and ar_text_id fields|
|Open||None||T174047 Hide deprecated/unused fields on toolforge replica [MCR]|
|Open||None||T200918 Make sure code that accesses the text table or uses rev_text_id triggers warnings before switching to write-new|
|· · ·|
- Mentioned In
- T194750: Deploy Structured Data on Commons baseline
T201164: Temporarily disable deprecation warnings for code that accesses rev_text_id or the text table directly
T198413: Allow multiple slots to be used while still writing to the old as well as the new schema
T191316: Schema change to make archive.ar_rev_id NOT NULL
- Mentioned Here
- T183490: MCR schema migration stage 4: Migrate External Store URLs (wmf production)
T174045: DB schema migration for MCR
T183488: MCR schema migration stage 2: populate new fields
The task description for this and T183488 says set to MIGRATION_WRITE_BOTH, run script to populate new tables, set MIGRATION_WRITE_NEW when finished. But the documentation of those constants seems to say that migration scripts should be run after setting MIGRATION_WRITE_NEW. Which is correct?
To some extent that depends on what exactly the migration script does.
If it looks primarily for rows without new data and doesn't delete the old data, it could run for WRITE_BOTH and the WRITE_NEW stage may not even be needed.
If the maintenance script looks primarily for rows with old data or deletes the old data after migrating it, then it should wait for WRITE_NEW so new old-data isn't being created.