高性能nosql ledisdbの設計と実現(2)
3375 ワード
ledisdbは現在replicationメカニズムをサポートしており、ledisdbの高可用性を保障しています.
使用
マスターのipが10.20.187.100、ポート6380、slaveのipが10.20.187.101、ポート6380とする.
まず、masterがbinlogサポートを開き、プロファイルで指定する必要があります.
slaveのマシンでは、プロファイルを使用してslaveofがreplicationを開くか、コマンドslaveofで表示されるオンまたはオフを指定できます.
ledisdbのreplicationメカニズムはredisおよびmysqlに関する実装を参照し,以下で簡単に説明する.
redis replication
redisのreplicationメカニズムは主にここで紹介されており,すでに詳細に説明されている. slaveはsyncコマンド をmasterに送信する. masterは、現在のデータをファイルにdumpし、新しい変更コマンド をメモリにキャッシュする.データdumpが完了するとmasterはslave に送信する. slaveは、dumpが完了するデータを受信した後、自機の以前のデータを空にし、dumpにインポートするデータ に格納する. masterは、以前にキャッシュするコマンドをslave に送信する.
redis 2.8以降、断線によるdumpの再生成を防止するため、redisはpsyncコマンドを追加し、断線時にmasterが現在の同期状態を記憶し、次回に断点再送を行うことができます.
mysql replication
mysqlのreplicationは主にbinlogの同期によって行われる.masterのデータ更新ではbinlogが書き込まれますが、binlogのフォーマットについてはここでは説明しません.
binlogのbasenameがmysql、indexファイル名がmysql-binと仮定する.index、現在のbinlogファイルをすべて記録します.
binlogにはmax file sizeの構成があり、binlogが書き込むファイルサイズがこの値を超えるとmysqlは新しいbinlogファイルを生成します.mysqlサービスが再起動されると、新しいbinlogファイルも生成されます.
Perconaのmysqlバージョンではbinlogにmax file numの設定があり、binlogのファイル数がこの値を超えるとmysqlが最初のbinlogを削除します.
slaveにはmasterがありますinfoのファイルは、現在同期しているmasterのbinlogの情報を記録するために使用され、主に現在同期しているbinlogファイル名とデータオフセット位置であり、次回の再同期時にその位置から継続することができる.
slave同期のデータはrelay logに書き込まれ、バックグラウンドにrelay logのデータがmysqlに格納される別のスレッドがあります.
マスターのbinlogが削除される可能性があるため、slave同期時にbinlogが失われる可能性があります.mysqlはdump+binlogで解決されます.つまり、slaveの完全なdumpマスターデータは、生成されたdumpにも現在のbinlog情報が同時に記録され、次回の同期を継続するのに便利です.
ledisdb replication
ledisdbのreplicationメカニズムはredisおよびmysqlを参照し、fullsyncおよびインクリメンタルsyncをサポートする.
masterはaofメカニズムではなくbinlogを使用し、max file sizeおよびmax file numを指定してbinlogの全体的なサイズを制御することで、aofファイルが増大し続けるために再rewriteを必要とするプロセスに関心を持つ必要はありません.
binlogファイル名のフォーマットは次のとおりです.
binlogファイル名の接尾辞は数値的に増加し,その後indexを用いて表す.
slave端子にもmasterがあります.infoファイルは、ledisdbがbinlogファイルの接尾辞の増加を厳格に保証するため、現在同期しているbinlogファイルの接尾辞のindexを記録するだけでよい.
Replicationプロセス全体は次のとおりです.初回同期または記録されたbinlog情報がmaster側binlog削除により一致しない場合、slaveはfullsyncを送信して全同期を行う. masterはfullsync情報を受信すると、現在のデータおよびbinlog情報をファイルにdumpし、slaveに送信します. slaveはdumpファイル全体が完了したことを受け入れた後、すべてのデータを空にし、同時にdumpのデータをleveldbにインポートし、現在のdumpのbinlog情報を保存する. slaveはsyncコマンドによりインクリメンタル同期を行い、syncコマンドフォーマットは以下の通りである: slaveはbinlogデータを受信し、leveldbをインポートします.syncが新しいデータを受信していない場合は、1 s後に再びsyncします.
最後に、masterに追加されたbinlogがslaveを同期させる方法について最も主要な問題です.これは2つのモデル、pushとpullにほかならない.
pushにとって、任意の新しいデータはslaveに非常にタイムリーに取得するように通知することができますが、pullモデルは性能を考慮するために、あまり頻繁にポーリングすることはできません.少し遅延します.
mysqlはpush+pullのモードを採用しており、binlogが更新された場合、slaveが更新されたことを通知するだけで、slaveはpullを通じて実際のデータを引き出します.しかしpushをサポートするために、masterはslaveのいくつかの状態情報を維持しなければならない.これは少し複雑さを増した.
ledisdbは非常に簡単な方法を採用しており、タイミングpullは、1 sの間隔を使用しており、ポーリングが頻繁すぎるためにパフォーマンスオーバーヘッドが増大することはなく、リアルタイムのデータ損失のリスクを最小限に抑えることができます.
まとめ
ledisdbのreplicationメカニズムは完成したばかりで、その後はまだ多くの改善が必要ですが、高可用性のnosql選択になるのに十分です.
ledisdbのURLはこちらですhttps://github.com/siddontang/ledisdbああ、興味のある子供靴が一緒に参加してほしいです.
使用
マスターのipが10.20.187.100、ポート6380、slaveのipが10.20.187.101、ポート6380とする.
まず、masterがbinlogサポートを開き、プロファイルで指定する必要があります.
use_bin_log : trueslaveのマシンでは、プロファイルを使用してslaveofがreplicationを開くか、コマンドslaveofで表示されるオンまたはオフを指定できます.
slaveof 10.20.187.100 6380ledisdbのreplicationメカニズムはredisおよびmysqlに関する実装を参照し,以下で簡単に説明する.
redis replication
redisのreplicationメカニズムは主にここで紹介されており,すでに詳細に説明されている.
redis 2.8以降、断線によるdumpの再生成を防止するため、redisはpsyncコマンドを追加し、断線時にmasterが現在の同期状態を記憶し、次回に断点再送を行うことができます.
mysql replication
mysqlのreplicationは主にbinlogの同期によって行われる.masterのデータ更新ではbinlogが書き込まれますが、binlogのフォーマットについてはここでは説明しません.
binlogのbasenameがmysql、indexファイル名がmysql-binと仮定する.index、現在のbinlogファイルをすべて記録します.
binlogにはmax file sizeの構成があり、binlogが書き込むファイルサイズがこの値を超えるとmysqlは新しいbinlogファイルを生成します.mysqlサービスが再起動されると、新しいbinlogファイルも生成されます.
Perconaのmysqlバージョンではbinlogにmax file numの設定があり、binlogのファイル数がこの値を超えるとmysqlが最初のbinlogを削除します.
slaveにはmasterがありますinfoのファイルは、現在同期しているmasterのbinlogの情報を記録するために使用され、主に現在同期しているbinlogファイル名とデータオフセット位置であり、次回の再同期時にその位置から継続することができる.
slave同期のデータはrelay logに書き込まれ、バックグラウンドにrelay logのデータがmysqlに格納される別のスレッドがあります.
マスターのbinlogが削除される可能性があるため、slave同期時にbinlogが失われる可能性があります.mysqlはdump+binlogで解決されます.つまり、slaveの完全なdumpマスターデータは、生成されたdumpにも現在のbinlog情報が同時に記録され、次回の同期を継続するのに便利です.
ledisdb replication
ledisdbのreplicationメカニズムはredisおよびmysqlを参照し、fullsyncおよびインクリメンタルsyncをサポートする.
masterはaofメカニズムではなくbinlogを使用し、max file sizeおよびmax file numを指定してbinlogの全体的なサイズを制御することで、aofファイルが増大し続けるために再rewriteを必要とするプロセスに関心を持つ必要はありません.
binlogファイル名のフォーマットは次のとおりです.
ledis-bin.0000001
ledis-bin.0000002binlogファイル名の接尾辞は数値的に増加し,その後indexを用いて表す.
slave端子にもmasterがあります.infoファイルは、ledisdbがbinlogファイルの接尾辞の増加を厳格に保証するため、現在同期しているbinlogファイルの接尾辞のindexを記録するだけでよい.
Replicationプロセス全体は次のとおりです.
sync binlog-index binlog-pos最後に、masterに追加されたbinlogがslaveを同期させる方法について最も主要な問題です.これは2つのモデル、pushとpullにほかならない.
pushにとって、任意の新しいデータはslaveに非常にタイムリーに取得するように通知することができますが、pullモデルは性能を考慮するために、あまり頻繁にポーリングすることはできません.少し遅延します.
mysqlはpush+pullのモードを採用しており、binlogが更新された場合、slaveが更新されたことを通知するだけで、slaveはpullを通じて実際のデータを引き出します.しかしpushをサポートするために、masterはslaveのいくつかの状態情報を維持しなければならない.これは少し複雑さを増した.
ledisdbは非常に簡単な方法を採用しており、タイミングpullは、1 sの間隔を使用しており、ポーリングが頻繁すぎるためにパフォーマンスオーバーヘッドが増大することはなく、リアルタイムのデータ損失のリスクを最小限に抑えることができます.
まとめ
ledisdbのreplicationメカニズムは完成したばかりで、その後はまだ多くの改善が必要ですが、高可用性のnosql選択になるのに十分です.
ledisdbのURLはこちらですhttps://github.com/siddontang/ledisdbああ、興味のある子供靴が一緒に参加してほしいです.