And I am not sure how we suposed to deal with errors like this, so I just leave this 'ack'-d as the db2095 is a sanitarium host for codfw - which is not in production now, it can wait until Monday. @jcrespo do you have any suggestions?

This is what I did for T208565: stop replication, add db.table to the long list of filters (carefully), let it catch up, then stop the replication on its master (beware of icinga alerts, downtime all possible alerts first), truncate the table without altering its definition and reimport it logically -eg mysqldump- (the triggers should take care of the sanitization), restore the replication filter to the original state and restart replication on the master.

That will fix the immediate issue correctly as its master users ROW based replication, but given this is the second time this happens -the first was T208565- we should identify a root cause and review (compare) all sanitariums on codfw, specially the archive table. This could be a codfw general issue, an application issue, or just a sanitarium import issue- it didn't happen on eqiad sanitariums even if they were identical not a long time ago.

I will try once the same thing- if it breaks again we should be thinking about a recloning (of a full preventive check on all archive tables). Also please comment there when you do a corrective measure e.g. "I did T208672#4718738 on section X, things went well/badly" so I am up to date with the status of the fix.

Sadly Manuel was the person to setup these so I don't know the details of how it was done.