I.はじめに
ここ数日、ネット上で業務完了後にデータが見つからないという問題が発生しており、最初は他のドキュメントの場所の検証だと思っていましたが、その後SQLをマスターに持って行きました。データベースとスレーブ データベースを確認してください。ライブラリにデータがないため、1 時間以上遅延しています。
二、調査
Mysql5.7 をオンラインで準同期モードで使用しています。dba と通信するとき、最初は同期モードだと思っていましたが、スタンバイ データベースの物理バックアップには毎朝 4 時間かかります。メイン データベースに ddl がある場合、スタンバイ データベースがスタックし、システムがライブラリからデータを読み取れませんでした。
いくつかの質問があります: ① 高可用性のためにバックアップ データベースを 1 日 1 回早朝にのみ使用するにはどうすればよいですか? リアルタイム同期すべきではないでしょうか?
②メインライブラリには ddl があり、システム書き込みにはまだ応答できるので、binlog データが更新中であることを意味します。スレーブライブラリは binlog を介して同期されています。データがないのはなぜですか?
で、改めて話をしたのですが、実際の構造は以下の通りです。
高可用性の準備として、メイン ライブラリ 2 はメイン ライブラリとリアルタイムで同期します。メイン ライブラリがダウンすると、メイン ライブラリになります。通常、データを復元するために早朝に物理バックアップ ファイルが生成されます。問題があった場合は前日まで。
log_slave_update が有効になっている場合でも、スレーブ ライブラリはカスケード同期に使用できる binlog も記録しますが、実際には遅延が比較的大きくなり、dba は依然としてメイン ライブラリをプルするように設定されます。スレーブ ライブラリのバイナリログは、データ ウェアハウスや Flink などのツールと同期できます。
メイン ライブラリ 2 は読み取りの一部としても使用されます。実際の遅延の理由は、システムがデータを読み取るときに、読み取られたドメイン名がメイン ライブラリ 2 に移動し、メイン ライブラリ 2 が物理バックアップを実行しているためです。バックアップがスタックすると、データの更新がブロックされます。
3、解決する
解決策はいくつかあります。
1. メイン ライブラリ 2 を読み取りクエリから除外します。これは当面計画されていません。後で検討すべき問題がまだある場合は、3 つのスレーブ ライブラリがすべてハングアップした場合はどうなりますか?
2. メインライブラリ 2 の物理バックアップのブロッキング時間を設定します。ブロッキング時間が一定時間を超えるとバックアップが停止され、しばらくすると最初からバックアップが開始されます。この方法は dba やブロガーに適しています。これは隠れた危険であると考え、バックアップ サイクルが継続的に行われる可能性があります。
3. 物理バックアップとLVM論理バックアップを組み合わせる、物理バックアップは週に1回で十分、LVM論理バックアップは毎日使う これはブロガーが読んでいる「ハイパフォーマンスMysql」でも推奨されている方法です 2を組み合わせても基本的には問題ありません。しかし、これには運用保守開発やバックアップ管理の自動化が必要であり、dbaは不必要だと感じます。
4. まとめ
これには、Mysql の同期とバックアップに関する基本的な知識が含まれます。ブロガーは書くのが面倒です。興味のある学生は、「High Performance Mysql」を読むとよいでしょう。
異なるアーキテクチャによって引き起こされる問題は、異なる最適化ソリューションに対応しており、興味のある人同士でコミュニケーションをとることができます。