MySQLオンラインログライブラリの移行例

最近の事例をお話ししましょう。オンライン Alibaba Cloud RDS 上のゲーム ログ ライブラリに最近問題が発生しました。ゲーム プレイヤーが増えるにつれて、オンライン ログ ライブラリのデータ量はどんどん大きくなりました。最新のログ ライブラリのサイズは 50G に達し、オンライン変更にかかる時間が非常に長くなりました。

これまで発見されなかった理由は、ログライブラリがこれまで変更されていなかったためです。しかし、業務が深まるにつれて、いくつかのゲーム属性を追加し、以前のログライブラリを変更する必要がありました。その結果、メンテナンスウィンドウが長くなったため、ビジネス側とDBAの両方がそれを躊躇し、ログの最適化が差し迫っていました。

まず、ログライブラリを見てみましょう。

1. ログ ライブラリには、データ量が 5,000 万を超える 5 つの大きなテーブルがあります。

2. これら 5 つのテーブルの月間データ量は、データ公開前は約 2,000 万ですが、データ公開後はさらに増加し​​ます。

3. 2つのテーブルのインデックスサイズがデータファイルのサイズを超えました

ビジネス側と運用側にこれらのテーブルに対する要件を尋ねたところ、次のとおりでした。

1. 過去 3 か月のデータのみを保存し、残りのデータはオンライン ビジネスのパフォーマンスに影響を与えないように循環させることができます。

2 ～ 3 か月前のデータは、クエリをサポートできるローカル データベースに転送する必要があります。クエリ速度は遅すぎてはならず、数分単位のクエリ速度が許容されます。

3. 移行プロセス中、ログ ライブラリはテーブル データの損失を数分間許容でき、データのリアルタイム同期に対する要件は高くありません。

4. オンラインログライブラリは、ユーザーアクティビティなどの統計情報をサポートする必要があります。

5. データベースとテーブルのシャーディングは実行したくありません。過去数か月間にクエリを実行する SQL 操作が多数あります。テーブル間には一定の結合があります。テーブルを分割しても、関連する操作には役立ちません。

上記の分析に基づき、実際の状況と組み合わせた当初の計画は次のとおりです。

1. オンライン データベース game_log 内のテーブルの名前を変更し、元のテーブルを再作成します。このプロセスは連続的ではなく、数秒分のデータが失われる可能性があります。具体的な操作は以下のとおりです。

#最初のステップは、テーブルの名前を game_log.table から game_log_bak.table に変更することです。

#2番目のステップはテーブル構造を取得することです。重要なのはauto_incrementの値です。
#3 か月以内にデータをインポートするときに競合が発生しないことを確認します。後でテーブル game_log_bak.table\G を作成します。

#3番目のステップは、game_logライブラリの2番目のステップのテーブル構造を再作成することです

2. 名前を変更した game_log_bak ライブラリ内のデータを、infobright ストレージ エンジンを使用してオフライン データの高速クエリをサポートするローカル オフライン データベースに転送します。

3. オンライン テーブル内の 3 か月以上前のデータ (約 40G) をバックアップしてクリーンアップし、オンライン game_log_bak データベース内の 3 か月以内のデータ (約 10G) を game_log データベースに再インポートします。構造は次のようになります。

4. game_log_bak ライブラリを削除し、次のように読み取り専用のスレーブ ライブラリを構築して、game_log ライブラリの情報をマスター ライブラリからリアルタイムで同期します。

5. ローカルの infobright データベースなどのローカル読み取り専用スレーブからデータを同期します。同期方法は、次のように dataX ツールを使用して選択できます。

6. 期限切れのオンライン データを一定の期間ごとにクリーンアップするスケジュールされたタスクを設定し、過去 3 か月間のデータのみがオンラインで保持されるようにします。これにより、RDS のディスク ストレージ領域に負担がかかりません。

現在、この方法にはいくつかの問題があります。

1. オンライン データを定期的にクリーンアップします。このデータによって占有されているテーブル スペースはすぐには再利用できないため、データ テーブルの断片化の問題が発生する可能性があります。

2. 将来的にゲームの規模が大きくなると、この問題が依然として残る可能性があります。その場合、ログ テーブルのクリーンアップ サイクルを適切に調整できます。データ量が大きすぎる場合は、他の解決策を検討して対処できます。

振り返ってみると、テーブルの設計にはまだいくつかの問題があります。ログテーブルにはフローデータのみを記録し、関連するクエリを避けるようにしてください。つまり、事前にデータ量を評価してから、四半期ごとまたは月ごとのテーブルを使用して、このような大量のログを処理することができます。これは、クリーニングやメンテナンスの際にはるかに便利かもしれません。

上記はMySQLオンラインログライブラリ移行例の詳細です。MySQLオンラインログライブラリ移行の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。