Cases33 cases

8 to 12 of 33

1. IL-0242 Both PostgreSQL servers behind matrix.org were lost during a disk expansion, and the homeserver was down for 24 hours

   Matrix.org Foundation2025

   Symptoms

   On 2 September 2025 the matrix.org homeserver went down at 17:45 UTC and stayed down until 18:00 UTC the next day. Both machines of its PostgreSQL cluster were out of action: the original primary had lost its RAID array during a disk expansion, and the data directory of the new primary had been deleted by mistake.

   Service outageData loss

   Trigger

   During maintenance to add drives, an existing drive disappeared from the primary database server's RAID 10 array at 11:17 UTC, which led to a failover and a rebuild of that server. The outage itself began when the data directory of the new primary on db-01 was deleted while clearing a failed restore on db-02.

   Root cause

   Operator error

   Component

   DatabaseDatabase backups and snapshotsDatabase replication

   Contributing factor

   Overlapping failuresHarmful manual actionUnpatched known bugNo safeguard on destructive change

   Detection

   Monitoring fired when the drive disappeared from db-02's RAID array at 11:17 UTC, and Mythic Beasts confirmed the issue. The team realised it had deleted db-01's data directory, and the backend team was then paged, an incident was opened and an emergency was declared.

   Remediation

   • Created a fresh RAID 10 array on db-02
   • Unblocked WAL archiving from the new primary on db-01 to S3
   • Started restoring db-02 from the S3 backups with wal-g
   • Shut down Synapse and the damaged primary database
   • Remounted the data partition of db-01 read-only
   • Copied the WALs missing from S3 from db-01 to db-02
   • Updated wal-g and patched it to continue from the partial restore
   • Configured a restore_command wrapper that fetched WALs from S3 and the local files, and replayed them in standby mode
   • Promoted db-02 to primary and restarted Synapse
   • Ran backups against the primary while no replica existed
   • Rebuilt db-01 as a replica from a base backup of db-02

   Action items

   • Run pg_repack to reclaim free space
   • Take incremental backups more often, since they restore faster than WAL replay
   • Reduce Synapse's storage requirements
   • Consider changing the terminal background colour by the database's role, for example by watching for the standby.signal file
   • Consider wrapper scripts around sensitive commands, such as an alias for rm, and automating operations such as starting a base backup from primary to secondary
   • Shorten the recovery time, with infrastructure from service providers
   • Upgrade wal-g on all servers and repeat disaster recovery testing with it
   • Explore ZFS local snapshots at the next hardware refresh
   • Make status.matrix.org the source of truth during incidents and keep social media updated

   Lessons

   Most of the difficulty came from the size of the database: restoring 51TB and replaying WALs took far longer than hoped, and incremental backups restore much faster than WAL replay. Running a destructive command on the wrong server was the turning point, and Matrix.org looks for better tooling and processes rather than blaming the individual; working as a trio did not catch the mistake, and server names that suggest a role caused confusion because a primary and a secondary swap roles. The recovery lost no data, but the recovery time needs to be shorter, and the wal-g versions on the disaster recovery server and the production servers had drifted apart.

   View case
2. IL-0527 OpenStreetMap.org made no replication diffs for 16 hours as PostgreSQL logical decoding failed on a memory alloc error

   OpenStreetMap Foundation2025

   Symptoms

   At 21:40 UTC on 25 June 2025, Alertmanager alerted the OpenStreetMap operations team: minutely replication feed delayed - 6m 2s. Since 21:33 UTC every run of the osmdbt timer that produces the minutely replication diffs had failed with ERROR: invalid memory alloc request size 1243650064.

   Replication lag

   Root cause

   Software defect

   Component

   Database replicationDatabase

   Contributing factor

   Pages not delivered

   Detection

   Alertmanager sent the first alert at 21:40 UTC, minutely replication feed delayed - 6m 2s, and several more followed, but none was a pager or SMS alert. A community report followed at 00:37 UTC and a social media report at 01:13 UTC.

   Remediation

   • Stopped the osmdbt timer
   • Put OpenStreetMap.org into a read-only maintenance window to suppress edits
   • Ran osmdbt by hand with fakelog to skip ahead of the PostgreSQL replication condition
   • Restarted the osmdbt timer for minutely diffs
   • Ended the read-only maintenance window

   Action items

   • Upgrade PostgreSQL to 17.x
   • Raise an issue with the PostgreSQL developers

   Lessons

   Communication with the osmdbt developer was crucial for working out the workaround, and the operations team's understanding of osmdbt was limited.

   View case
3. IL-0376 A maintenance update set off needless full syncs between Upstash Redis replicas in eu-west-1, slowing the databases

   Upstash2025

   Symptoms

   On 25 February 2025, regional Upstash Redis databases in AWS eu-west-1 slowed down after a maintenance update, with very high CPU load on databases that have a replica in that region. Latency stayed high until about 21:23 UTC, even after the affected databases were unthrottled at 15:06 UTC.

   High latencySustained high node CPU

   Trigger

   A maintenance update to the regional Upstash Redis databases in AWS eu-west-1.

   Root cause

   Software defect

   Component

   In-memory cacheDatabase replication

   Contributing factor

   Automation amplification

   Remediation

   • Added more resources to the regional eu-west-1 cluster
   • Unthrottled the affected databases at 15:06 UTC and enabled more throughput

   Action items

   • Deploy a fix that stops regional databases from starting unnecessary full synchronisations
   • Contact regional database users about migrating to Upstash Global, which does not have this issue

   View case
4. IL-0526 OpenStreetMap.org went offline, then read-only, for 56 hours after HE.net routing equipment cut both fibre uplinks

   OpenStreetMap Foundation2024

   Symptoms

   At 04:01 UTC on 15 December 2024, StatusCake monitoring sent SMS alerts that OpenStreetMap.org was unreachable. The website and the mapping API had gone completely offline at 03:53 UTC.

   Network unreachableService outage

   Trigger

   HE.net's routing equipment in Amsterdam failed at 03:53 UTC on 15 December 2024.

   Root cause

   Dependency failure

   Component

   ISP and transit networksDatabase replication

   Contributing factor

   Single point of failureNo runbook

   Detection

   StatusCake monitoring detected the outage at 04:01 UTC and sent SMS alerts, and the incident was reported to the operations team at once.

   Remediation

   • Activated a read-only backup instance of OpenStreetMap.org in Dublin
   • Brought a new Equinix Internet link into service in Amsterdam, bypassing HE.net and restoring full functionality
   • HE.net replaced its routing hardware and restored its service, and routing through HE.net resumed

   Action items

   • Move to a multi-ISP architecture so another provider can take over when one fails
   • Research backup ISPs for the Amsterdam servers, including BGP and keeping HE.net as a fallback
   • Add deeper route and latency monitoring and an automated escalation protocol
   • Hold failover drills for switching between ISPs and keep replication up to date
   • Agree SLAs with HE.net and Equinix Internet with defined escalation procedures and response times
   • Prepare the 4G out-of-band system as a manual fallback uplink that can sync Postgres replication data, and upgrade its hardware
   • Document outage communication procedures and delegate communication during outages
   • Investigate decoupling the OAuth service so authentication keeps working while the database is read-only

   Lessons

   Relying on HE.net alone left the Amsterdam servers with a single point of failure, so OpenStreetMap will keep multiple upstream providers. The 4G out-of-band link proved invaluable and should be able to carry data synchronisation. Resumed replication would have restored editing faster than the read-only backup. Frequent contact with the ISP gave no useful estimates, so the SLA needs to be better understood. Alerting on upstream connectivity needs refining, and a read-only OpenStreetMap.org also blocked logins to services that were not affected, because it could not save new tokens.

   View case
5. IL-0392 MariaDB replication of section x1 between eqiad and codfw broke on a missing heartbeat row during a cookbook run

   Wikimedia Foundation2024

   Symptoms

   On 18 September 2024, while a cookbook was reconfiguring Wikimedia's core MariaDB databases from one-way eqiad -> codfw replication to circular replication ahead of a datacenter switchover, replication in the codfw -> eqiad direction broke on the x1 and es6 sections. Engineers watching the run noticed at 21:28 UTC that the x1 primary was not replicating.

   Replication lag

   Trigger

   Running the cookbook sre.switchdc.databases.prepare, which set up codfw -> eqiad replication and started pt-heartbeat, on the row-based x1 and es sections.

   Root cause

   Configuration change

   Component

   DatabaseDatabase replication

   Contributing factor

   Monitoring blind spotGap in automated testsHarmful manual action

   Detection

   Engineers watching the first run of the automation saw on orchestrator that the x1 primary was not replicating, because monitoring of circular replication was not yet enabled. The break in the eqiad -> codfw direction was reported by Icinga.

   Remediation

   • Skipped replication of the heartbeat tables with Replication_wild_ignore_table='heartbeat.%'
   • Inserted the missing heartbeat row with binary logging off on the es hosts
   • Inserted the missing heartbeat row with binary logging off on the x1 codfw hosts and removed the ignore rule

   Action items

   • Avoid the same issue again, probably by inserting the missing row when it is detected
   • Add a post-maintenance health check that replication works in both directions
   • Add options to run the maintenance in another order or on each section individually
   • Update the Phabricator task for each section rather than only at the end
   • Fix the monitoring gaps for circular replication
   • Made pt-heartbeat-wikimedia use STATEMENT format for its session on the x1 and row-based read-write es hosts, fixed in a later deploy

   Lessons

   Circular replication is not a normal working mode, so the first fix only moved the break to the other side; TRUNCATE would have worked better than DELETE because it always replicates as a statement, but it was not considered because it is more dangerous. Running sql_skip_slave_counter was avoided, since it could have made things worse or lost data. The check of the replication channel should also run once all tasks are complete, not only right after setup. The combination of row-based replication, pt-heartbeat and differing heartbeat rows was not described in earlier maintenance or documentation.

   View case

By root cause11