GitHub、1200台以上のMySQL 5.7を8.0へアップグレード - サービス無停止移行の戦略
概要
GitHubが1200台以上のMySQL 5.7を、サービスレベルを維持したままMySQL 8.0にアップグレードした事例。期間は1年以上かけて慎重に実施。
背景とスケール
インフラ構成
- プラットフォーム: Microsoft Azure（仮想マシンとベアメタルサーバー）
- サーバー数: 1200台以上
- 構成: 50以上のクラスタ（各クラスタは1プライマリ + 複数レプリカ）
- 可用性: 高可用性と高性能を実現
アップグレードの目的
- セキュリティ: MySQL 5.7のEOL対応
- パフォーマンス: 8.0の性能向上機能の活用
- 新機能: 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ヶ月 | 全クラスタの段階的移行 |
| 安定化 | 継続 | モニタリングと最適化 |
まとめ
大規模なデータベース移行において重要なのは：
- 綿密な計画: リスクの洗い出しと対策
- 段階的実施: 一度にすべてを変更しない
- 十分なテスト: 本番環境と同等の検証
- モニタリング: 問題の早期発見
- ロールバック準備: いつでも戻れる状態を維持
- チーム連携: 組織全体での協力
GitHubの事例は、エンタープライズレベルのデータベース移行における優れたベストプラクティスを示している。