サービスと「コピー」によるデータの高可用性の性質はマルチコピー機構によって行われる完全な、冗長データにサービス複数のマシンにクラスタ化など、解決します。サービスのために、複数のインスタンスを配置するだけでよいが、特に、ステートレスサービス、一般的なマイクロ・サービス（ダボ/スプリングクラウド）はほとんど常にサービス機能を提供するためにクラスタ化されることができ、それは+ドッカーさらにK8Sにも使用することができます自動管理サービスの技術的能力のコピー;データについては、データがステートフルであるため、データ複製ノードを介してデータの一貫性を確保する必要がある、のでサービスコストをコピーするよりも難しい達成が高くなっています。
（改良されたデータレプリケーションの部屋に複数の部屋の耐障害性）よりも複製の可用性を向上させることに加えて、あなたはまた、別の読み取りなど、パフォーマンスを向上させ、より近いようなユーザへのデータのコピーを書くことができ、利用者は、近くのデータの優先順位を読むことができます。このようRedisのスナップショットとして、スナップショット - データ、一般複製、マルチマスターレプリケーションと非マスター・レプリケーション、これらに加えて、だけでなく、共通のからの主な共通のレプリケーション戦略の戦略を「コピー」。本論文では、いくつかのレプリケーション戦略は、上記の分析のためにいくつかの単語の小さな男、レッツ・ゴー〜を発売しました
データ複製を分析することである。この論文ではフォローアップの議論のための特別な指示をコピーしていない、重複がここで議論したノードに基づいているデータは、過剰なゾーニング機構の使用を必要とし、スコープのメカニズムの外側をゾーニングするので、前提条件として、すべてのデータを保存することができます内:(
マスタースレーブのレプリケーション
データが時間とともに変化していない場合、あなたは、単に一回コピーすることができ、難易度のコピーは、データが常に変化しているので、このような障害に対処するというようにする方法のかどうか同期レプリカとしてコピーに多くのトレードオフが存在するです。マスタースレーブのレプリケーションは、共通のレプリケーション戦略で、データの書き込みは、プライマリ・サイトで発生した後、ノードからの更新に同期します。以下からモデルベースのレプリケーションマスタ：
主は、内蔵などのPostgreSQL（バージョン9.0から）、MySQLのは、Oracle Data GuardのとSQL Serverなどの多くのデータベースの機能からコピーされ、当然のことながら、いくつかの非リレーショナルデータベースもありますまた、などのMongoDB、などの機能を、サポートだけでなく、データベース高可用性を実現するだけでなく、マスター・スレーブ複製を達成するために、カフカ（マルチコピーパーティション）とRabbitMQのキューのような、さらにいくつかの記憶装置自体のは、複製機構を有します。
同期および非同期レプリケーション
重要な詳細のレプリケーションは、同期レプリケーションまたは非同期レプリケーションプライマリ・データベースに障害が発生した場合、より多く持っているが、ライブラリから対応するデータを見つけることを保証することができ、データの整合性を確保するために、同期レプリケーション;しかし、欠点は、ライブラリからであろうと、また非常に顕著ですレプリケーションのパフォーマンスが遅く、ライブラリーからの障害やネットワーク自体た場合、ホストはライブラリーからライブラリまでの要求を処理できない、またはネットワークが正常になるまで。ライブラリからマルチシーンでは、異常なシーンデータベースから単一のネットワークの異常や障害のために、コピーに（例えば、同期機構から主飼育係など）はほとんどのノードクォーラム機構OKを確保するために使用することができる限り、ライブラリからコピーまたはブロードキャストとして（例えばMySQLの準同期機構のような）コピーにOK。
より良いパフォーマンスを確保するための非同期レプリケーションは、非同期要求の処理には影響しません、プロセスはマスターノード要求が、それは一貫性の究極の現れであるため、非同期レプリケーション後の要求を処理し続けることができ、いくつかのデータの矛盾の期間があります。プライマリ・データベースに障害が発生した場合、すべてが失われます、データベースからのデータに同期されていません。非同期レプリケーション戦略を使用すると、ビジネスはデータ要件の高い一貫性を持っている場合、あなたはマスターノード処理に同期レプリケーションメカニズムや要求を使用することができ、ほとんどのシナリオでビジネスシーンに応えることができるようになります。
ライブラリーからの新しいです
時には、どのように交換するか、ライブラリからライブラリーから、障害を追加する必要があることを確認するためにそのライブラリからの新しい一貫性のあるデータとメインライブラリそれ？メインライブラリーをロックして、スナップショットが推奨されていないコピーして、可用性の原則に反するので、データは常に可能な更新が行わあるため、ライブラリから新しいスナップショットのマスターノードからの単純なコピーデータは、十分ではありません。新しいライブラリを開始してから、次のように、理論的には、機械を停止することなく行うことができます。
-
いくつかの時点で、メインライブラリのスナップショットを取得し、ほとんどのデータベースは、この機能を持っています。
-
スナップショットは、ライブラリから新しいノードにコピーして適用されます。
-
変化からのデータは、マスター・リポジトリに接続した後、スナップショットは、プライマリ・データベースのスナップショット・コピーの位置を必要とするトリガが、正確ように日付⼆バイナリブログ座標（バイナリログ座標）MySQLのように、ログを関連付けることができる引っ張り始める生じます。
-
ライブラリからキャッチメインライブラリ、両方の整合性のある状態は、その後のデータを処理し続けることができるときに変更されます。
いないすべてのシーンでは、このようないくつかのデータベースレプリケーションプロトコルをアップグレードすると、ライブラリーから新しいので、ノンストップすることができから下位互換ライブラリではなく、次のコピー、パーティションの拡張シーンを待ちます。
ログのコピー
マスター・スレーブ複製層は、（先行書き込みログ）WAL上、声明に基づき、例えば、以下のスキームを構成し、ログベースのトリガーの行に基づいて、異なるプログラムは、以下の簡単な分析を別の長所と短所を持っています：
-
声明に基づいて：同期する最も簡単な方法は、各更新文（UDPATE /削除/作成）のための主要なライブラリは、ライブラリに転送され、解析へのローカルライブラリから適用した後に、このアプローチは、合理的なようだが、SQLが含まれている場合現在の時間を取得するために）非文関数の値を決定し、それが（例えばNOWとして、ライブラリーからの一貫性のないマスターになります。
-
WALベース、PostgreSQLとデータはインデックスページまたは同等のランダム書き込みに直接書き込まれ、先行書き込みログは追記モードで順次書き込まれ、より高いパフォーマンスので、通常、先行書き込みに基づいて、データベースのデータ復旧機能は、達成するためにログインします。このOracle、コピー方法を使用して、主な欠点は、日付データロギングがしばしば便利底に来ている：WALディスクブロックどのエンジンコンパクトに収納複製を作るアフター変更（例えばMySQLのREDOログ）を、含まれているバイトカップリング。データベースには、バージョン⼀からフォーマット変更を保存する場合は、別のタイムバージョンのメイン・ライブラリでリポジトリデータベースソフトウェアから別のバージョンを実行している場合、通常は不可能です。
-
列に基づいて、ログ、更新操作、列線の更新ログに含まれる前後に、また一般的に、論理ログとラインサイズに基づいて、データ書き込みシーケンス、行の挿入を説明するためのリレーショナルデータベースを呼ぶ、行は、ログのすべての列の値が含まれています。値は、MySQLのは、このようにして達成ログのbinlog（ステートメントモード）に基づいています。
-
トリガーベース：いくつかの戦略の複製の上記機構は、トリガー機構に基づいて、データベース自体に設けられているデータが更新されたコピーの論理演算に対応するときに対応するユーザプログラムをトリガするためにアプリケーション・コードを含みます。
レプリケーションの遅延の問題
レプリケーションレイテンシ問題非同期レプリケーションモード、ネットワークサービスの異常または異常な遅延の問題がより深刻であり、いくつかのビジネスデータの待ち時間公差は、このような更新ユーザ情報として、他のユーザーに見える大きさである、一定の時間遅延それは関係ありません。別々の読み取りと書き込みのシナリオでは、読み取りは、ライブラリから行くことであると、ユーザーはただ単に言うことです失われた更新データを、同様に、情報の表示情報または古い更新しています長い遅延がある場合に 使用世帯は書き込みがあります古いコピーからデータを読み込んだ後、このような状況は、一貫性を確保するために読み書きする必要があります。これは⼀保証は、ユーザーリロード使用⻚⾯場合、彼らは常に彼らは自分の提出すべての更新プログラムが表示されます。これは、書き込み保護他の世帯を使用へのコミットメントをしない：他のユーザーが待機して使用して更新が表示されます。ユーザーが自分失うSTARTが正しく保存されていることを確認するために使用します。
マスター・スレーブレプリケーションのシナリオでは、それは読んで一貫性のある書き方をすべきですか？更新されたデータを読み出すために、メインのライブラリまたはユーザーを行くために自分の更新情報を表示するために、現在のユーザとして、プライマリ・データベースからデータを読み込むためのシーンが必要な遅延であっ複製することができることは明らかであり、すべての最初には、メインライブラリーの完了後などに行っています。アップデートは公開情報（複数のユーザーが同時に編集できる）である場合は、クライアント側の更新タイムスタンプを増やすことができ、最新のタイム・スタンプの一定時間内のすべての読み取り操作は、メインのライブラリを行っています。
マルチマスターレプリケーション
マスター・スレーブレプリケーション操作は更新できないクライアントは、メインデータベースに接続できない場合は、メイン図書館に行くを更新する必要があり、複数のノードが書き込み操作を受け取ることができ、マルチマスターレプリケーション戦略をベースにしています。まだ同じ髪⽣シャッターモードをコピーします。各処理ノードは、そのようなマルチルームなど、ライブマルチコピーライティングは、マルチマスターとして知られているマルチ設定（のリーダーとして知られている他のすべてのノードに転送したデータの変更でなければなりません生きるための場所）。この場合には、リーダーのそれぞれは、他の指導者の追随を再生しながら。
マルチマスターレプリケーションのシナリオ
より一般的なマルチマスタ複製シナリオでは、データセンタは、複数のデータセンターの各データセンターとの間のマスタ - スレーブ同期を使用して、各データセンター内で、メインライブラリを持つ必要があり、データセンターのメインライブラリでマルチマスタ複製でありますコピーメインデータベースの他のデータセンタ、マルチマスタ複製複数のデータセンターは、以下のように：
多数据中心对于公司服务运维能力要求较高，一般只有较大公司才玩的转，毕竟是有一定成本的。多数据中心对于服务来说，需要进行挺大的改造的，比如主键ID就需要接入分布式ID方案，不能采用单机数据库的ID自增方案；多数据中心的多主复制方案可以容忍数据中心停机而不中断服务，大大提高公司对外服务高可用性。
写入冲突
讨论多数据中心的写入冲突之前，先看下协同编辑场景中存在的写入冲突问题，协同编辑比如google docs允许多人同时对一个文件进行编辑操作，为了解决冲突，可以采取用户在编辑前锁定文档，然后编辑之后另一个用户才能编辑，但是这种方案锁粒度太大，因此可以使用更小粒度的方案，比如针对文档中的一个单元格进行锁定操作。
多领导者复制的最⼤问题是可能发⽣写冲突，这意味着需要解决冲突，常见的冲突解决可以采用版本思想，比如按照最新时间戳，最大版本号等，但是这种方案可能导致数据覆盖丢失问题；除了版本思路之外，还可以保留冲突数据，当用户再次查看数据时，让用户选择使用哪一个冲突版本的数据，比如git的merge冲突等。
无主复制
⼀些数据存储系统采⽤不同的⽅法，放弃主库的概念，并允许任何副本直接接受来⾃客户端的写⼊。由于无主复制没有主库概念，但是也要保证多副本机制，因此需要在客户端向多个从节点进行写操作，比如bookkeeper的写入策略，就是客户端并发些，只要收到大多数数据节点的ack就认为此次数据写入成功，这样就能保证数据的“一致性”。
快照技术
快照技术就是将当前数据状态存储到文件，便于存档，当故障发生时可以使用最近一次的快照恢复数据，由于快照执行一次的成本相对较大，但是为了保证快照数据具有实时性，因此会折中在多少次更新操作或者多长时间后触发一次快照操作，比如Redis会默认当900s内有一次更新操作，或者300s内有10次更新操作，或者60s内有10000次更新操作，就会触发RDB持久化（Redis数据快照）。常说的快照技术也就是全量数据保存，还有一种是增量数据保存，比如Redis中的AOF持久化策略。
小结
俗话说，要想提高可用性就进行一次复制操作；如果再想提高可用性，那就再复制一次。复制的本质是冗余数据，提高可用性，注意，复制也不是冗余越多越好，毕竟越多网络开销更大，从而影响整体服务性能，需要根据特定场景特定考虑，一般针对数据来说，冗余3份即可。
复制可分为同步复制和异步复制两种模式，一般来说前者有较高的数据一致性保证，后者有更好的性能保证。复制策略常见的有主从同步、多主同步和无主复制等，主从同步模式容易理解，无主复制需要应用程序多做一些额外的操作保证数据一致性。快照技术也是一种复制模式，常见于本地数据的归档保存，比如于故障恢复场景。复制是为了解决高可用问题，如果数据量更大，往往会使用分区+复制的策略来保证高性能和高可用性。
推荐阅读