大規模なMySQLデータベース用のマスタースレーブシステムを構築するアイデアを共有する

今週は戦争のように忙しかったです。他人に操られているような気がします。毎日朝早く出勤して夜遅く帰り、やるべき仕事は尽きません。DBA は良い仕事ではないと感じることもあります。強いストレス耐性と精神的忍耐力が必要です。今日の午後、昼食を食べているとき、本当に倒れそうになりました。しかし、夕食後、仕事を終えて家に帰ることにしました。通りを歩きながら、仕事を終えて帰る人々の群れを見て、私は思いました。これは仕事を終える普通の時間ではないのか？なぜ私はまだ早く帰ることを恥ずかしく思うのだろう？もしかしたらその人全体が洗脳されているのかもしれません。

今週の公式アカウントコンテンツの更新は2日遅れました。火曜日は疲れていたのでそのままお休みしました。 昨晩、退社する時は9時頃でした。一日の仕事でとても疲れていて、頭が言うことを聞いてくれませんでした。誤動作を起こして、オンライン環境のアカウント権限テーブルを削除してしまいました。すると、その環境は新しく、バックアップもされていないことがわかりました。私は打ちのめされ、天が落ちてくるような気分でした。幸い、私は普段から変更を保存する習慣があり、以前ビジネス パーティに公開したアカウント権限が自分の txt ファイルの中にあるのを見つけました。サービスが利用可能かどうか、同期がタイムリーかどうかのテストを含め、修正に2時間かかりました。帰ってきて時間を見ると、すでに11時半でした。急いで公式アカウントに書き込んだのですが、書き終わったときにはもう深夜だったので、公式アカウントは更新しませんでした。

この気持ちは本当に最悪です。この文章をどこで見たのかはわかりませんが、「IT 担当者をダメにする一番の方法は、成長の時間がなくなるほど忙しくさせることです。」私は今、この悪循環に陥っているように感じます。かつて友人が私に言った言葉を思い出します。「会社で忙しく働いているときは、時々顔を上げて前を見るべきだ。」

早く慣れられるといいなと思います。北京に引っ越した人は、きっと私と同じような気持ちになっていると思います。忙しさの定義は人それぞれでしょう。この点では、パブリックアカウントの視聴者の皆さんの共感を得られるかもしれませんね ^_^。

長々と無意味なことを言ってしまいました。文句を言うだけでは問題は解決しません。今に集中して、役に立つことを書きましょう。皆さんのお役に立てれば幸いです。私自身のまとめとも言えます。

大規模データベースでマスタースレーブシステムを構築する方法

今朝、会社に行ったら、問題が発生しました。アラーム情報によると、分散クラスター内の一部のマスターとスレーブの関係がダウンしており、つまりスレーブデータベースが切断されていました。その後、原因を調べたところ、ビジネス関係者と別の同僚が同時にマスターデータベースにデータをインポートしていたためであることがわかりました。この2人が実行した操作は依存関係があり、大量のトランザクションが関係していました。競合により、トランザクションがロールバックされ、スレーブデータベースはロールバックするデータが存在しないことを検出したため、スレーブデータベースが切断されました。

この問題を見て、まずスレーブライブラリの修復を試みました。gtid を使用して構築されたマスタースレーブレプリケーションだったので、set next gtid メソッドを使用して修復しようとしました。具体的な方法は、gtid の記事で確認できます。記事は公式アカウントの下部に分類されています。その後、begin; commit; set automatic gtid を実行して、問題が解決したことを確認しましたが、約 5 分後に再び問題が発生しました。明らかに、この方法は長期的な解決策ではなく、ビジネス側から流入していないデータがまだたくさんあります。さまざまな選択肢を検討した後、最終的にスレーブ ライブラリを再構築する必要がありました。

メインデータベースのデータ量を調べたところ、約100Gありました。直感的に思いついた方法は以下の2つです。

1. サーバーに直接バックアップする

2. リモートNFSマウントされたバックアップマシンにバックアップする

これら 2 つの方法を見ると、サーバー自体に使用できる空き容量はそれほど多くありません。強制バックアップも可能ですが、ディスクアラームが発生するため、決して良い方法ではありません。さらに、xtrabackup 方式を使用する場合、ログの適用とコピーバックの 2 つの手順に長い時間がかかります。

リモート NFS バックアップ マシンを見てみましょう。バックアップ マシンは容量が大きく、ディスクの問題を解決しますが、リモート転送に必要な帯域幅を提供できません。バックアップを並列で実行すると、帯域幅が確実に不足し、同時バックアップ プロセスが遅くなります。控えめに見積もっても、マスター スレーブ 5 セットで約 8 時間かかります。

それで私たちは何をすべきでしょうか?ここでは比較的大まかな方法​​が使われています。取引先と直接通信し、サービスを一時停止し、2 台のマシン間の ssh 相互信頼を開き、scp ツールを構成し、物理的なファイル コピーによってスレーブ ライブラリにファイルを直接コピーします。100G のファイルを圧縮および解凍するには時間がかかるため、圧縮は実行されません。これを行う利点は次のとおりです。

まず、各バックアップは分離されており、他の環境の影響を受けません。

2 つ目: マスター データベース上のネイティブ ファイルをマシン間の帯域幅を介してスレーブ データベースにインポートし、完全なデータ整合性を確保できます。

3番目: 時間の短縮

それでやってみたところ、ざっと調べたところ、SCP を使用して 100G のファイルをコピーするのに約 17 分しかかからないことがわかり、バックアップ時間が長いという問題が解決しました。 5 つのウィンドウが互いに影響を与えることなく並行して実行されるため、5 つの環境からのデータのアップロードには約 30 分しかかかりません。これで、マスター データベースとスレーブ データベースのデータが完全に整合しました。次に、スレーブ データベースの構築を開始します。必要な作業がいくつかあります。

1. マスター データベースのコピーされた my.cnf ファイルをスレーブ データベースの元の my.cnf ファイルに置き換えます。そうしないと、server_id が重複し、マスター/スレーブ設定でエラーが発生します。

2. ライブラリ内の元の slave-relay-log.index ファイルを新しいディレクトリにコピーします。そうしないと、マスタースレーブを構築するときに、ファイルが見つからないというメッセージが表示されます。

3. スレーブ ライブラリの UUID を変更します。これは、GTID レプリケーションを構築するときに使用する必要があります。マスター スレーブ環境を繰り返すことはできません。そうしないと、サービスが利用できなくなります。この UUID の変更は通常、現在のライブラリの UUID 値を保存する auto.cnf ファイルで行われます。

4. スレーブ データベースでスレーブをすべてリセットし、auto_position=1 のレプリケーション モードを使用してマスター スレーブ レプリケーションを構築します。マスター スレーブを構築した後、マスター スレーブ データの一貫性を確認します。

5. スレーブ データベースで読み取り専用オプションを設定して、スレーブ データベースでの直接の DML 操作を禁止します。

上記は、大規模な MySQL データベースのマスター スレーブ関係を構築するアイデアを共有する詳細な内容です。大規模な MySQL データベースのマスター スレーブ関係の構築の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。