Post

GitHub、1200台以上のMySQL 5.7を8.0へアップグレード - サービス無停止移行の戦略

Posted
By rengotaku
8 min read

概要

GitHubが1200台以上のMySQL 5.7を、サービスレベルを維持したままMySQL 8.0にアップグレードした事例。期間は1年以上かけて慎重に実施。

背景とスケール

インフラ構成

  • プラットフォーム: Microsoft Azure（仮想マシンとベアメタルサーバー）
  • サーバー数: 1200台以上
  • 構成: 50以上のクラスタ（各クラスタは1プライマリ + 複数レプリカ）
  • 可用性: 高可用性と高性能を実現

アップグレードの目的

  1. セキュリティ: MySQL 5.7のEOL対応
  2. パフォーマンス: 8.0の性能向上機能の活用
  3. 新機能: CTE、Window関数などの利用

無停止移行の戦略

1. 段階的アプローチ

フェーズ1: 検証環境でのテスト

  • 本番と同等の環境を構築
  • アプリケーションの互換性確認
  • パフォーマンステスト
  • ロールバック手順の確認

フェーズ2: レプリカから開始

プライマリ (5.7) → レプリカ1 (5.7) → レプリカ2 (8.0)
  • まずレプリカを8.0にアップグレード
  • レプリケーションの動作確認
  • 読み取りトラフィックの段階的移行

フェーズ3: プライマリの切り替え

旧プライマリ (5.7) ← 新プライマリ (8.0) ← レプリカ (8.0)
  • レプリカを新プライマリに昇格
  • 旧プライマリを新プライマリのレプリカに変更
  • 問題発生時は即座にロールバック可能

2. 主要な技術的課題と解決策

互換性の問題

課題:

  • SQL構文の非互換性
  • デフォルト設定の変更
  • 文字セット・照合順序の変更

解決策:

-- 互換性チェック mysqlcheck --check-upgrade -- アプリケーションログの監視 -- 非推奨な構文の検出と修正

パフォーマンスの変動

課題:

  • クエリオプティマイザの動作変更
  • インデックス選択の変更
  • 一部クエリのパフォーマンス劣化

解決策:

-- クエリプランの比較 EXPLAIN FORMAT=JSON SELECT ...; -- ヒントの使用 SELECT /*+ INDEX(table_name index_name) */ ...; -- 統計情報の更新 ANALYZE TABLE table_name;

3. モニタリングと観測

監視項目

  • レプリケーションラグ: 遅延の監視
  • クエリパフォーマンス: スロークエリの検出
  • エラーレート: 新しいエラーの発生
  • リソース使用率: CPU、メモリ、ディスクI/O

ツール

  • カスタムモニタリングダッシュボード
  • アラート設定
  • 自動ロールバック機能

学んだ教訓

1. テストの重要性

  • 本番環境の完全なレプリカでテスト
  • すべての主要なユースケースをカバー
  • 負荷テストとストレステスト

2. 段階的移行

  • 一度にすべてを変更しない
  • 各ステップで検証
  • 問題の早期発見と修正

3. ロールバック計画

  • すべてのステップでロールバック可能に
  • ロールバック手順の文書化
  • 定期的なロールバック訓練

4. コミュニケーション

  • チーム間の密な連携
  • ステークホルダーへの定期報告
  • 問題発生時の迅速な情報共有

実装のベストプラクティス

1. 事前準備

# バックアップの確認 mysqldump --all-databases > backup.sql # 設定ファイルの比較 diff my-5.7.cnf my-8.0.cnf # 互換性チェック mysql_upgrade --version-check

2. アップグレード手順

# 1. レプリカでの実施 # レプリケーション停止 STOP SLAVE; # MySQL 8.0インストール yum install mysql-community-server-8.0 # アップグレード mysql_upgrade -u root -p # レプリケーション再開 START SLAVE; # 2. プライマリ切り替え（計画的フェイルオーバー） # 新プライマリへの昇格 STOP SLAVE; RESET SLAVE ALL; # 旧プライマリの降格 CHANGE MASTER TO ...; START SLAVE;

3. 検証

-- バージョン確認 SELECT VERSION(); -- レプリケーション状態確認 SHOW SLAVE STATUS\G -- パフォーマンス確認 SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

タイムライン

フェーズ 期間 内容
計画 2ヶ月 要件定義、リスク分析、手順書作成
テスト環境構築 1ヶ月 本番同等環境の構築
互換性テスト 3ヶ月 アプリケーション検証、修正
パイロット移行 2ヶ月 小規模クラスタでの実施
本番移行 6ヶ月 全クラスタの段階的移行
安定化 継続 モニタリングと最適化

まとめ

大規模なデータベース移行において重要なのは：

  1. 綿密な計画: リスクの洗い出しと対策
  2. 段階的実施: 一度にすべてを変更しない
  3. 十分なテスト: 本番環境と同等の検証
  4. モニタリング: 問題の早期発見
  5. ロールバック準備: いつでも戻れる状態を維持
  6. チーム連携: 組織全体での協力

GitHubの事例は、エンタープライズレベルのデータベース移行における優れたベストプラクティスを示している。

参考リンク

database
mysql database migration github infrastructure
This post is licensed under CC BY 4.0 by the author.