I only analyzed enwiki on s1, but I wouldn't be surprised if discrepancies like these existed for other DBs too.
- Different PRIMARY KEYs:
- 6 servers (the non-contributions eqiad slaves: db1053, db1057, db1065, db1066, db1072, db1073) have PRIMARY KEY(rev_id). This is the sane thing to do, and what MediaWiki's tables.sql prescribes.
- 7 servers (the eqiad master: db1052; and the non-special codfw slaves: db2016, db2048, db2055, db2062, db2069, db2070) have PRIMARY KEY(rev_page, rev_id). All of these also have UNIQUE KEY(rev_id).
- 4 servers (the contributions slaves in both eqiad and codfw: db1051, db1055, db2034, db2042) have PRIMARY KEY(rev_id, rev_user). These servers do not have any sort of unique constraint on rev_id. It's still an auto-increment field, and we will probably (hopefully?) never rotate a contributions slave into the master position, so we hopefully won't ever get duplicate rev_id values, but the fact that not all servers have a uniqueness constraint scares me.
- Presence of an index on (rev_page, rev_id)
- Per the above, 7 servers have this as their primary key
- The 6 servers that have PRIMARY KEY(rev_id) also have a key on (rev_page, rev_id)
- The 4 servers that have PRIMARY KEY(rev_id, rev_user) do not have a key on (rev_page, rev_id) at all
- Presence of the rev_timestamp key: what's in this key varies (see below), but 2 servers (db1065 and db1066) don't have it at all. If there were code that used FORCE INDEX(rev_timestamp), that could cause query errors. (I don't believe there is, nor can I think of anything that uses this index offhand; I wonder if it's used.)
- rev_id padding for the rev_timestamp, page_timestamp, user_timestamp, usertext_timestamp and page_user_timestamp indexes
- On 7 servers (all eqiad servers except db1052 and db1066), these indexes have rev_id as their last field.
- On db1066, page_timestamp does not have rev_id at the end, but the other indexes do
- On the other 9 servers (db1052 and all codfw servers), these indexes do not have rev_id at the end
- Partitions on the contributions slaves
- The codfw contributions slaves (db2034 and db2042) have identical partitions for rev_user, going up to 28M
- db1051 has a much smaller set of partitions, stopping at 24M
- db1055 has almost the same partitions as db1051, but does not have the ones at 50K and 24M
- The non-contributions servers do not have these partitions, by design