コピー
複製手段は、ネットワークで接続された複数のマシン上で同じデータのコピーを保持します。難易度は、コピーを変更するプロセスは、データを複製していることです。我々はなり
リーダーとリーダーを超えない、単一リーダー：3つの人気の変更コピーアルゴリズムを議論していません。ほとんどすべてのこれらの3つの方法のいずれかを使用して分散データベースの。
マスタースレーブ構成
各ノードのデータベースストレージは、レプリカコピーと呼ばれます。どのようにすべてのデータがコピーのすべてに該当することを確実にする：複数のコピーが存在する場合には、避けられない問題があるでしょうか？
たびに、書き込み動作は、すべてのコピー上のデータベースに伝播される必要があり、またはコピーは異なるデータが含まれています。最も一般的な解決策は、以下のように動作し、アクティブ/パッシブのか、マスター/スレーブレプリケーションとして知られているリーダーベースのレプリケーション、として知られています：
- 一つのコピーもメインライブラリ（マスター）として知られているリーダー（指導者）として指定されています。クライアントがデータベースを書きたいときには、指導者にリクエストを送信する必要があり、リーダーはそのローカルストレージに新しいデータを書き込みます。
- また、読み取り専用として知られている他のコピーフォロワー（フォロワー）と呼ばれているが、ライブラリー（スレーブ）から、（レプリカを読む）ホットスタンバイをコピーします。新しいデータのリーダーがローカルストアに書き込まれるたびに、レプリケーションログとして知られているすべての信者に送信されたデータを、変更したり、流れが変わります。各フォロワーログからリーダーを引っ張って、データベースのローカルコピーを更新は、アプリケーションはすべてのリーダー処理のために同じ順序で記述されています。
- クライアントがデータベースからデータを読みたいときは、指導者や信者を照会することができます。しかし、唯一のリーダーは、書き込み操作を受け入れることができます（ライブラリからクライアントの観点から、読み取り専用です）。
このパターンは、内蔵などのAlwaysOn可用性グループのPostgreSQL、MySQLのは、Oracle Data GuardのとSQL Serverなどのリレーショナルデータベースの機能、多くの複製されます。また、MongoDBは、RethinkDBやエスプレッソなど、いくつかの非リレーショナルデータベースで使用されています。最後に、リーダーベースのレプリケーションは、データベースに限定されるものではない：カフカと可用性の高い分散型のメッセージ・キューこのような薬剤のようなRabbitMQのもそれを使用しています。例えば、のようないくつかのネットワークファイルシステムは、ブロックコピーDRBD装置もこれに類似です。
同期レプリケーションと非同期レプリケーション
同期レプリケーションの利点は、ライブラリからのデータのメインライブラリーの最新のコピーと一貫性があることを保証するために、ということです。メインライブラリーの突然故障した場合、我々はデータがまだライブラリで見つけることができることを確認することができます。不利な点は、ライブラリ同期（それが崩壊したような、またはネットワーク障害、またはその他の理由）からの応答がない場合、プライマリ・データベースは、書き込み動作を処理することができない、ということです。主なライブラリは、すべての書き込みをブロックし、同期コピーが再び使用可能であるのを待たなければなりません。
したがって、ライブラリからのすべてが同期に設定されていることは非現実的である：ノードのどれ中断がシステム全体が停滞する原因となります。他の人が非同期である一方、実際には、あなたは、通常、同期されているフォロワーを意味するデータベース、上の同期レプリケーションを有効にした場合。同期は、同期、非同期を作るためのライブラリから、ライブラリから使用できないか、遅くなった場合。ライブラリーからのメインライブラリと同期：あなたは、少なくとも二つのノード上のデータの最新のコピーを持っていることを、この保証します。この構成は、時には準同期と呼ばれます。
通常の状況下では、ベースのレプリケーションの指導者は、完全に非同期のために設定されています。この場合、いずれかの書き込みにコピーされていない場合は、メインライブラリーが回復不可能無効にされている場合、ライブラリから欠落します。クライアントが正常に書き込みを確認した場合であっても、この手段は、持続的な保証することはできません。しかし、完全に非同期の構成も利点があります：すべての主要なライブラリーの背後にあるライブラリからある場合でも書かを処理し続けることができます。
新しいライブラリを設定するから、
クライアントは、データは常に変化している、データベースにデータを書き込み続け、データの標準コピーが常に異なる時点では異なるであろう。コピー結果には何の意味も持たないかもしれません。あなたは、一貫性のあるディスク上のファイルに（それが書き込みに使用することはできません）データベースをロックすることができますが、これは、高可用性の目標に反するだろう。ライブラリから新しいプルダウンは、一般的に必要とされていません。次のように概念的には、手順は次のとおりです。
- データベース全体をロックすることなく、いくつかの点一貫したスナップショット（可能な場合）で、メインのライブラリを取得します。バックアップする必要があるため、ほとんどのデータベースでは、この機能を持っています。いくつかのシナリオでは、あなたは、このようなMySQLのinnobackupex [12]などのサードパーティ製のツールを、必要な場合があります。
- 新しいノードにライブラリからスナップショットをコピーします。
- すべてのデータは、ライブラリとプルスナップショットの変化へのライブラリーから、メインの接続後に発生します。これは、マスター・データベースの複製に関連する位置ログの正確なスナップショットが必要です。異なる名前の位置：例えば、PostgreSQLのログ・シーケンス番号（てLogSequence番号LSN）と呼ばれるが、MySQLはバイナリログ座標（バイナリログ座標）と呼びます。
- ライブラリーからのバックログは、スナップショットデータが変更に加工された後にするとき、我々はそれが（キャッチアップ）メインライブラリをキャッチ言います。今では、メインのライブラリの変更によって生成されたデータを処理し続けることができます。
プライマリ・データベースの障害 - フェイルオーバー
図書館の新しいメインライブラリから推進するための一つのニーズは、あなたが他のライブラリから、新しいメインライブラリーへの書き込み操作を送信するために、クライアントは新しいプライマリ・データベースからのデータ変更を引っ張って起動する必要があり再構成する必要があります。次のステップ：
- 主なライブラリを確認するために失敗しました。クラッシュ、停電、ネットワークの問題など：多くの間違って行くことができるものがあります。各ノードは、頻繁に前後にメッセージを送信し、一定の期間内のノードは、（例えば30秒）応答しない場合、それがハングアップと見なされます。問題の発生を検出するための何の確実な方法は、ほとんどのシステムは、単にタイムアウトを使用し、ありません。
- 新しいメインライブラリを選択します。これが完了するために選択プロセスを介して（一次ライブラリにコピーし、残りの多数決によって生成される）、または選択したコントローラ前に、新しいプライマリ・データベース・ノードによって指定することができるかもしれません。メインライブラリーのための最良の候補者は、通常、古いメインライブラリーライブラリー（データ損失を最小限に抑える）からのデータの最新のコピーを持っています。
- 新しいメインライブラリーを有効にするためにシステムを再構成。クライアントは、今、彼らは新しいメイン図書館にリクエストを書き込む必要が。古い指導者が戻ってきた場合、あなたはまだメインライブラリとして自分自身を考えることが、他のコピーは、それが辞任したことに気付いていません。システムは、ライブラリになってから、古いリーダーシップが新しいリーダーシップを認識していることを確認する必要があります。
コピー実装
基づい文をコピーします
最も単純なケースでは、メインデータベースの各書き込み要求のレコードと、それはそのライブラリーからログに送信されたステートメントを実行します。リレーショナルデータベース、手段についてそれぞれのINSERT、UPDATE、またはDELETE文は、ライブラリからそれぞれに転送されていることは、それぞれのライブラリから解析され、同じクライアントから受け取ったとして、SQL文を実行します。しかし、多くの問題がある。このコピーモードを台無しになります。
- 非決定的関数への呼び出し（非決定性）の文は、各コピーに異なる値を生成することがあります。例えば、現在使用（）現在の日付と時刻を取得し、またはRAND（）を使用して乱数を取得します。
- 各コピーに正確に同じ順序で実行されなければならない自動インクリメントを使用して文（自動インクリメント）、またはデータベース内の既存のデータに依存（<ある条件>例えば、UPDATE ...）、ならそうすることで、異なる結果を生成することができます。限界とすることができる、同時に実行する複数のトランザクションがある場合です。
- 文の副作用副作用が絶対的に決定されない限り（例えば、トリガー、ストアドプロシージャ、ユーザ定義関数）は、各コピーに異なる効果を生じることがあります。
トランスミッション先行書き込みログ（WAL）
どのような変更が含まれWALバイトのディスクブロック。これは、密結合、複製やストレージエンジンになります。データベースはバージョンからバージョンへのフォーマットの変更を保存する場合は、メインのライブラリには通常不可能であるとライブラリからデータベースソフトウェアの異なるバージョンを実行します。
複製論理ログ（行ベース）
別の方法は、コピーすることで、店舗エンジンは、コピーがログストレージエンジンの内部から単離することができるように、異なるログ・フォーマットを使用します。これは、論理複製ログログは別の（物理的な）エンジン・データ・ストアで発現されることが呼び出されます。
通常シーケンスを記録記載論理関係データベース・ログの粒子サイズは、データベーステーブルの行に書かれています。
- 挿入された行のために、ログは、すべての列の新しい値を含みます。
- 行が削除されたために、ログが削除された行を一意に識別するための十分な情報が含まれています。通常は主キーが、テーブルには主キーが存在しない場合、あなたはすべての列の古い値を記録する必要があります。
- 行を更新するために、ログを一意に更新された行を識別するのに十分な情報、および新しい値（新しい値または列が変更されたその少なくともすべて）すべての列を含んでいます。
修正複数行のトランザクションは、トランザクションが提出されたことを示す、記録に続いて複数のこのようなログを生成します。この方法を使用して（使用行ベースのレプリケーションに構成された）MySQLのバイナリログ
トリガーベースのレプリケーション
トリガーは、カスタム・アプリケーション・コード・データの変更（書き込みトランザクション）が自動的に行わ行わ、データベースシステムに登録されています。データを変更するもう1つのシステムにコピーされた後、別のテーブルにトリガー変更する機会は、テーブルは、外部プログラム、および任意のサービスロジック処理を用いて読み出されます。
レプリケーションの遅延の問題
メインライブラリベースのレプリケーションは、すべての書き込み処理は、単一のノードで構成されて必要としますが、唯一のクエリは任意のコピーによって処理することができます。だから、少しのシーンを読み書きするために、1つのオプションは、ライブラリから多くのことを作成することです。この拡張されたアーキテクチャでは、単により多くのフォロワーを追加するには、読み取り専用のサービス要求の容量を増やすことができます。しかし、このアプローチは、実際には非同期レプリケーションに適用されます。非同期のアプリケーションがライブラリから読んだとき残念ながら、ライブラリから後方にあれば、それは古い情報が表示されることがあります。ここではいくつかの可能な解決策があります
読むには、私たち自身を書きます
あなたがページをリロードした場合、彼らは常に彼らが提出することを任意の更新情報が表示されます。これは、他のユーザーの書き込みへのコミットメントをしない：他のユーザーが表示されますため、更新が待つことがあります。これは、ユーザー自身の入力が正しく保存されていることを保証します。
- ユーザーの読み取りがメインライブラリーから読み込まれた内容を変更した可能性場合は、実際のユーザークエリはいくつかのことを変更することができるかどうかを知ることなく、これは、いくつかの方法が必要です。例えば、メインライブラリーからユーザー自身のファイルを読んで、ライブラリから他のユーザーのファイルを読み込みます。
- コンテンツ・アプリケーションの大半は、ユーザーを編集することができた場合は、コンテンツのほとんどは、メインライブラリから読み取らなければならないので、このアプローチは、無用であること。この場合、あなたは、メインのライブラリから読み込んするかどうかを決定するために他の基準を使用することができます。たとえば、最後の更新後1分以内に、最後の更新の時間を追跡、メインライブラリーから読み取ります。
- クライアントは、元のタイムスタンプを変更するには、ユーザのためのライブラリーからのすべてのお問い合わせは、ライブラリからこれに普及していることを保証するために、システムのニーズをスタンプが書き込まれる最後の時間を思い出すことができます。
単調な読書
あなたが複数回異なるライブラリから読み込む場合は、このような状況で発生することがあります。まず、クエリライブラリーからの小さな遅延、および、ライブラリから長い遅延。
ユーザーは順次何度も読めば以前より新しいにデータを読み込む場合、彼らは、ある時間の背中を、見ないことを唯一の手段を読んで単調には、それ以降はより古いデータを取得することはできません読み込みます。
同じプレフィックスを読みます
あなたが書かれた順序のシリーズを押すことが起こるならば、誰もが、これらが書かれた読み、あなたは彼らが同じ順序で表示されます。
データベースの特定の部分古いを参照することができる異なるパーティション独立ので、グローバルな書き込みシーケンスが存在しない、ユーザーがデータベースからデータを読み出し、これは特に問題パーティション（断片）データベースであります状態、および新しい状態でいくつか。
マルチマスタ構造
データセンター間、各データセンターの主なライブラリは、メインライブラリーの他のデータセンターの変化にコピーされます。
最大の問題は、競合を解決する必要性を示唆したマルチリーダーコピー書き込み電位の競合、あります。いくつかの方法がある競合を解決するために合併を実装します。
- 各書き込み一意のID（例えば、タイムスタンプ、乱数、UUIDやハッシュキーと値の長さ）のために、最高のIDの選択は、勝者として書き込まれ、他の書き込みを破棄されます。
- 各コピーに一意のIDに割り当てる、高いID番号は、より高い優先度で書かれています。
- 紛争での明示的なデータ構造に記録されている全ての情報を保持し、（利用者の道を促すことで、おそらく）競合を解決するために、アプリケーション・コードを記述すること。
いいえ一次構造ありません
書き込み用クライアントの代わりに、一方、他の例では、コーディネータノードいくつかの非リーダーを実装するには、クライアントは、複数のコピーを送信するために直接書き込まれます。しかし、主なライブラリデータベースは、特定の書かれた順序のコーディネーターは実行されません。リーダーシップの設定がない場合には、フェイルオーバーが存在しません。
ユーザーの応答は2を決定するために受信された後、私たちは書き込みが成功したと思う：2の3つのコピーが書かれたと仮定すると認めるには十分です。お客様は、単純にコピーの1つが書き込みを逃したという事実を無視します。
- クライアントは、並列された複数のノードを読み出したときに、任意の失効応答を検出することができる：修復を読み取ります。
- アンチエントロピー法：バックグラウンド・プロセスでいくつかのデータ・ストレージ、プロセスがコピーされ、別のコピーを1つのコピーから欠落しているデータのコピー間の不一致を探し続けています。
コピーは、nがある場合、各書き込みが成功を確認するためにwをノードによって考慮されなければならない、と我々は、少なくとも2 = wは、我々の場合には（各リードクエリノードをR、N = 3でなければなりません、R = 2）。長いN + R> Wとして、我々は最新の読み取り値を得ることを期待したよう、読書などのRの少なくとも1つのノードが最新の状態にあります。これらの値以下（定足数）Wの値を読み出し、書き込み、読み出し及び書き込みクォーラムと称するであり、R。