Admin/MirrorNotes

Here are some scattered thoughts that might be useful when following Admin/MirrorHowto.

We don't put either volatile data or data that is easily rebuilt into the dumpfile. This makes each incremental changeset noticeably smaller.

Here are a few ways that mirrors are different from the master:

The mirror database is configured read-only (LocalSettings.php). If the user tries to edit somthing, it will say something like "database locked for maintenance."
No user tables are sent to the mirror. You can only browse on a mirror -- you can't log in.
The page counters are all zeroed. If we didn't do this, we'd get rows in the dumpfile every time someone so much as visits a page. That's a lot of churn.
Each page is individually protected against edits. This is what hides the Edit tab.
The fulltext index is dropped. It needs to be rebuilt each time you do an update.
Page history remains intact, but the Recent Changes link is empty. You can rebuild the recent changes table if you want. I don't know why you'd want to, however.

Here is some more information about the incremental updates.

The database and the application must be updated at the same time.
The fulltext index must be rebuilt after each update.
The recently-edited table is optional. If you want it in your mirror, though, you must rebuild it too.
All caches must be flushed after updating. The dump script takes care of truncating the objectcache. If you have enabled file or memory caching, however, you will have to flush those yourself (they come disabled unless you changed these settings on your mirror).

These assume that you have a working php command-line executable. Run php --version.

Rebuilds the text index:

  php maintenance/rebuildtextindex.php

Flushes the cache:

  php maintenance/rebuildrecentchanges.php