These are used to avoid spamming the logging table servers we route traffic to for MW. They are disable now (T92591). Ideally these could just separately poll themselves up to date rather than use SPOFy master/slave setups. This would work cross-DC too. Disabling AoF and using daily RDB snapshots might handle persistence (or we could just have none). MW already knows when the filter is stale and avoids in in such cases.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T88445 MediaWiki active/active datacenter investigation and work (tracking) | |||
| Resolved | PRODUCTION ERROR | aaron | T92591 rbf1001 and rbf1002 are timing out / dropping clients for Redis | ||
| Declined | aaron | T93006 Figure out a cross-DC strategy for the BloomFilter caches |
Event Timeline
Comment Actions
Change 199514 had a related patch set uploaded (by Aaron Schulz):
[WIP] Made bloom filter servers just tail updates from slaves
Comment Actions
Change 199514 abandoned by Aaron Schulz:
[WIP] Made bloom filter servers just tail updates from slaves
Comment Actions
Change 201684 had a related patch set uploaded (by Aaron Schulz):
Removed BloomFilter classes
Comment Actions
@aaron, do I understand this right that rbf100x aren't used/going to be used? Do we need to decommission those servers or are you planning on using them somehow? If it's the former, we'll need a separate task for this.
Comment Actions
Change 201997 had a related patch set uploaded (by Faidon Liambotis):
Remove bloom filter store configuration