MySQLレプリケーション環境でAUTO_INCREMENT列を追加するマイグレーションを実施したところ、ソースとレプリカでIDの割り当て順序が異なる事態が発生。binlog_formatがMIXEDだったため、5つの関連テーブルはSTATEMENT形式で正しくレプリカ側のIDを参照できたが、AUTO_INCREMENT関連の操作はMySQLがROW形式に自動切り替えするため、1つのテーブルだけソース側のIDがそのままコピーされ、レプリカ上では全く別の行を指す不整合が発生した
Monzoが構築した独立バックアップ基盤「Monzo Stand-in」の解説記事。主系（AWS上の約3000マイクロサービス）とは別に、GCP上で約18サービスからなる完全に独立したスタンバイ環境を用意し、カード決済や送金、残高確認など重要機能のみを限定的に提供する。強整合性のレプリケーションではなく非同期・結果整合のデータ同期を採用し、主系とは別のコードベースで実装することで同一障害への耐性を高めている。運用コストは主系の約1%に抑えられており、2024年8月の大規模障害時に実際に稼働した実績を紹介している。
バックアップの終了コードは「処理が最後まで走った」ことしか保証せず、復元可能性は別問題である。復元性を①走ったか②あるか③開けるか④足りているか⑤戻せるかの5段階に分け、各段が次を保証しないことを示す。④（量が足りているか）は正解データの置き場所を自分で決める必要があり最も難しく、⑤（実際に戻せるか）は人手でしか確認できない代理不可能な検証である。頻度と強さは逆相関するため、下から順に埋めるのではなく頻度×強さで運用を設計すべきと結論づける。
GitHubが8月17日に7時間47分に及ぶ大規模障害を起こし、認証・Actions・API・PR・Issue・Copilotなど広範なサービスが影響を受けた。原因は中央データセンターのインフラコンポーネントがトラフィックのピークにスケールできなかった容量問題で、Copilotのリトライループが復旧を遅らせた。GitHubはAzureへの移行加速（プラットフォーム負荷の約58%をAzureが処理）、CPUコアやストレージの増強、リトライ制限の統一、モノレポの読み取り性能改善などの再発防止策を進めている。