Commons copy on s3, s4 and s6 are corrupted. The versions at s1 and s5 are not affected.
Test case: mysql -h $server commonswiki_p -e "SELECT page_title FROM page where page_id=21683917"
Good: +------------------------------+ | page_title | +------------------------------+ | Dworzec_główny_w_Gdyni.jpg | +------------------------------+
Bad: +----------------------+ | page_title | +----------------------+ | Dworzec_główny.jpg | +----------------------+
It looks like a range of statements from November 2012 weren't replicated.
Other tests are:
SELECT log_id, log_title, log_type, log_action FROM logging_ts_alternative where log_namespace=6 AND log_title='Dworzec_główny.jpg'" The wrong copies don't have «| 48917341 | Dworzec_główny.jpg | move | move |» (the other 7 entries appear in both)
SELECT rev_id, rev_timestamp, rev_comment FROM revision where rev_page=21683917 The wrong copies don't have the last 4 revisions (all of them from 2012-11-03)
'Dworzec_główny_w_Gdyni_4.jpg', 'Dworzec_główny_w_Gdyni_3.jpg', 'Dworzec_główny_w_Gdyni_2.jpg' are similarly affected, shown as just Dworzec_główny_0X.jpg in the wrong dbs.
Comparing the number of revisions per day, it seems to have fixed on 2013-11-04, with the 3 being the most noticeable (27746 revisions where they should have been 53974), a difference of 80 revisions the previous day, 200 on 2012-10-27...
It should be possible to just copy the db from s1.
s1 and s5 are probably sane due to the reimports on January and April.
As an unexpected thing, sql-s2 and sql-s7 don't have a commonswiki_p copy. sql-s3 and sql-s6 don't have a commonswiki_p.revision table/view.
toolserver-l@lists.wikimedia.org