MySQL の高可用性設計ソリューション。MySQL だけの最適化だけではまだプレッシャーに耐えられない場合は、現時点では MySQL クラスター ソリューションを検討する必要があります。現在実現可能なソリューションは次のとおりです:
利点: 非常に高い可用性と非常に優れたパフォーマンス。各データの少なくとも 1 つのコピーを異なるホストに保存でき、冗長データのコピーはリアルタイムで同期されます。メンテナンスが面倒で、いくつかの脆弱性があるため、重要なオンラインシステムでの使用はお勧めしません。
このソフトウェアには次の利点があります: 強力な機能があり、基盤となるデバイス レベルでさまざまな物理ホスト間でデータを迅速にミラーリングでき、パフォーマンスと信頼性 性的ニーズにより、さまざまなレベルの同期が構成されます。 IO 操作は順序を維持するため、データの一貫性に関するデータベースの厳しい要件を満たすことができます。
ただし、非分散ファイル システム環境では、ミラー データの同時表示をサポートできません。パフォーマンスと信頼性は相反するものです。パフォーマンスと信頼性の要件が厳しい環境には適用できません。メンテナンス コストは他よりも高くなります。 MySQL レプリケーション。そのため、実際の環境に合わせて導入するかどうかを検討することができます。
MySQL レプリケーションは、システムのスケーラビリティを向上させるために実際のシナリオ設計で広く使用されています。多くの MySQL ユーザーはレプリケーション機能を通じてシステムのスケーラビリティを向上させた後、低価格のハードウェア デバイスを追加するだけで元のシステムのパフォーマンスを 2 倍、さらには向上させることができました。 -range MySQL ユーザーに非常に好まれており、多くの MySQL ユーザーが MySQL を選ぶ最も重要な理由の 1 つです。
従来の MySQL レプリケーション アーキテクチャが他にもいくつかあります。ここではそれらについて簡単に説明します。
MySQL レプリケーション ソリューション 1: 従来のレプリケーション アーキテクチャ マスター/スレーブ。1 つのマスターから 1 つのマスターまたは 1 つのマスターに複製されます。 Salve のアーキテクチャ モデルは、主に読み取り圧力の高いアプリケーションのデータベース側での安価な拡張ソリューションに使用され、読み取りと書き込みが分離され、マスターが主に書き込み圧力を担当します。
MySQL レプリケーション ソリューション 2: カスケード レプリケーション アーキテクチャ、つまりマスター-スレーブ-スレーブ。これは、スレーブに対する過度の読み取り圧力を防ぎ、接続されたスレーブの問題を簡単に解決できるセカンダリ スレーブの層を構成するためでもあります。マスター側では多すぎるとボトルネックになる危険性があります。
MySQL レプリケーション オプション 3: デュアル マスターとカスケード レプリケーションを組み合わせたアーキテクチャ、つまりマスター-マスター-スレーブの最大の利点は、メインのマスターの書き込み操作がスレーブのレプリケーションの影響を受けることを回避できることです。クラスタ、およびメインマスターの単一障害点が保証されます。
MySQL レプリケーションの欠点: マスター ホストのハードウェア障害を回復できない場合、スレーブに送信されなかった一部のデータが失われる可能性があります。したがって、誰もが現在のネットワーク計画に基づいて独自の合理的な MySQL アーキテクチャ ソリューションを選択し、MySQL DBA およびプログラマーと通信し、複数のバックアップを作成し (少なくともローカルおよびオフサイトのバックアップを作成します)、より多くのテストを行い、データを最も多く取得する必要があります。重要なことは、間違いがあってはいけないので、覚えておいてください。
以上が一般的な MySQL 高可用性設計ソリューションは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。