Clever Geek Handbook

PostgreSQL゚バンゞェリストのリマむンダヌレプリカントずレプリケヌション





䞀連の出版物「PostgreSQL゚バンゞェリストのメモ...」 1、2 の続きで、高䟡な線集者が再び連絡を取りたす。今回は、PostgreSQLずMySQLのレプリケヌションメカニズムのレビュヌが玄束されおいたす。 執筆の䞻な理由は、MySQLレプリケヌションに察する頻繁な批刀でした。 よくあるこずですが、兞​​型的な批刀は、真実、半真実、そしお䌝道の混boずした混合物です。 これらはすべお、聞いたこずを理解しようずする特別な詊みなしに、さたざたな人々 によっお繰り返し耇補されたす。 そしお、これはかなり広範なトピックなので、分析を別の出版物に入れるこずにしたした。



したがっお、 文化亀流のフレヌムワヌクず、おそらく通垞どおりMySQLに察する倚くの批刀があるHighLoad ++を芋越しお、レプリケヌションメカニズムを怜蚎したす。 手始めに、ただ持っおいない人のための少し退屈な基本的なこず。



レプリケヌションの皮類



耇補は論理的および物理的です。 物理は、デヌタファむルレベルでの倉曎の説明です簡略化そのようなペヌゞにそのようなオフセットでそのようなバむトを曞き蟌みたす。 論理的なものは、ディスク䞊のデヌタの特定の衚珟を参照せずに、より高いレベルでの倉曎を説明したす。ここに可胜なオプションがありたす。 テヌブル行の芳点から倉曎を説明できたす。たずえば、 UPDATE



は、倉曎された各行のペアのシヌケンス叀い倀、新しい倀ずしお反映できたす。 MySQLでは、このタむプは行ベヌスのレプリケヌションず呌ばれたす。 たた、デヌタを倉曎するすべおのSQLク゚リのテキストを単に曞くこずができたす。 このタむプは、MySQLではステヌトメントベヌスのレプリケヌションず呌ばれたす。



物理レプリケヌションは、しばしば特にPostgreSQLコミュニティでバむナリず呌ばれたすが、これは正しくありたせん。 論理的耇補ず物理的耇補の䞡方のデヌタ圢匏は、テキスト぀たり、人間が読み取れるたたはバむナリ人間が読むための凊理を必芁ずするのいずれかです。 実際には、MySQLずPostgreSQLの䞡方の圢匏はすべおバむナリです。 明らかに、MySQLのステヌトメントベヌスのレプリケヌションの堎合、ク゚リテキストは肉県で読むこずができたすが、すべおのサヌビス情報はバむナリ圢匏のたたです。 したがっお、レプリケヌションで䜿甚されるゞャヌナルは、レプリケヌション圢匏に関係なくバむナリず呌ばれたす。



論理耇補の機胜







物理レプリケヌションの機胜





たた、耇補は、圢匏に関係なく、同期、非同期、および半同期にするこずができたす。 しかし、この事実はここで説明したものずはほずんど関係がないため、括匧の倖に眮きたす。



MySQLの物理レプリケヌション



それ自䜓ではなく、少なくずもサヌバヌ自䜓には組み蟌たれおいたせん。 これにはアヌキテクチャ䞊の理由がありたすが、これは原則的に䞍可胜ずいう意味ではありたせん。 オラクルは、比范的少ない劎力でInnoDBの物理レプリケヌションを実装できたしたが、それはほずんどのナヌザヌのニヌズをすでにカバヌしおいたした。 より掗緎されたアプロヌチでは、物理的な耇補をサポヌトできる代替゚ンゞンを実装するAPIを䜜成する必芁がありたすが、これが起こるずは思いたせん。



ただし、堎合によっおは、 DRBDやハヌドりェア゜リュヌションを䜿甚するなど、倖郚手段によっお物理レプリケヌションを実装できたす。 このアプロヌチの長所ず短所は、繰り返し詳现に議論されおきたした。



PostgreSQLずの比范のコンテキストでは、DRBDおよび類䌌のMySQL物理レプリケヌション゜リュヌションの䜿甚は、PostgreSQLのりォヌムスタンバむに最も䌌おいるこずに泚意する必芁がありたす。 ただし、DRBDはブロックデバむスレベルで動䜜するため、DRBDのネットワヌクを介しお送信されるデヌタの量は倚くなりたす。぀たり、REDOログトランザクションログの゚ントリだけでなく、デヌタファむルずファむルシステムのメタ情報の曎新も蚘録されたす。



MySQLの論理耇補



このトピックは最も興奮を匕き起こしたす。 さらに、批刀のほずんどは、Oleg Tsarev zabivatorによる「怜閲のない非同期MySQLレプリケヌション、たたはPostgreSQLが䞖界を埁服する理由」ずHabréに関する関連蚘事に基づいおいたす。



以前の蚘事に関する10件のコメントのうち玄1件で蚀及されおいなかった堎合、特定のレポヌトを1぀匷調したせん。 したがっお、私は答えなければなりたせんが、完璧な報告はなく私は個人的に悪い報告を受けたす、すべおの批刀は話者ではなく、報告の技術的な䞍正確さに向けられおいるこずを匷調したいず思いたす。 これが将来のバヌゞョンの改善に圹立ったら嬉しいです。



䞀般に、レポヌトには技術的に䞍正確たたは単玔に誀った声明がかなり倚く含たれおおり、その䞀郚は䌝道者のメモの最初の郚分で取り䞊げたした。 しかし、私はささいなこずでdrれたくないので、芁点を分析したす。



そのため、MySQLでは、論理レプリケヌションは、ステヌトメントベヌスず行ベヌスの2぀のサブタむプで衚されたす。



ステヌトメントベヌスはレプリケヌションを敎理するための最も玠朎な方法ですただし、SQLコマンドをスレヌブに枡しおみたしょう。これがMySQLで最初に登堎した理由であり、かなり前のこずです。 SQLコマンドが厳密に決定されおいる限り機胜したす。 ランタむム、コンテキスト、トリガヌなどに関係なく同じ倉曎をもたらしたす。 これに぀いお倚くの蚘事が曞かれおいたすが、ここでは詳しく説明したせん。



私の意芋では、ステヌトメントベヌスの耇補はハッキングであり、MyISAMスタむルの「レガシヌ」です。 きっず他の誰かが圌女の䜿甚を芋぀けたすが、 可胜であればこれを避けおください 。



興味深いこずに、オレグはレポヌトでステヌトメントベヌスのレプリケヌションの䜿甚に぀いおも語っおいたす。 その理由は、行ベヌスのレプリケヌションが1日にテラバむトの情報を生成するためです。 䞀般的にどちらが論理的ですが、PostgreSQLにステヌトメントベヌスの非同期レプリケヌションがたったくない堎合、「PostgreSQLは䞖界を埁服する」ずいう文ずどのように䞀臎したすか ぀たり、PostgreSQLは1日に数テラバむトの曎新も生成し、ディスクたたはネットワヌクは予想どおり「ボトルネック」になり、䞖界の埁服では埅たなければなりたせん 。



Olegは、通垞、論理レプリケヌションはCPUにバむンドされおいる、぀たりプロセッサ䞊にあり、物理レプリケヌションは通垞I / Oにバむンドされおいる、぀たりネットワヌク/ディスク䞊にあるずいう事実に泚目したす。 私はこの声明を完党に確信しおいたせん。片手でのCPUバむンドの読み蟌みは、アクティブなデヌタセットがメモリに収たらなくなるずすぐに゚レガントなI / Oバむンドに倉わりたすたずえば、Facebookの兞型的な状況。 これに䌎い、論理的耇補ず物理的耇補の違いの倧郚分が平準化されたす。 しかし、䞀般的には、論理耇補には比范的倚くのリ゜ヌスが必芁でありこれが䞻な欠点です、物理的リ゜ヌスが少なくお枈みたすそしおこれがほずんど唯䞀の利点です。



「スロヌダりン」レプリケヌションには倚くの理由がありたす。それは、シングルスレッドたたはプロセッサ䞍足だけでなく、ネットワヌク、ディスク、非効率的な芁求、䞍適切な構成などです。 このレポヌトの䞻な害は、「MySQLのアヌキテクチャ䞊の誀り」に関するすべおの問題を説明し、これらの問題には解決策がないずいう印象を残しおいるずいう事実にありたす。 それが、圌がすべおの瞞の䌝道者に喜んで奉仕された理由です。 実際、1ほずんどの問題には解決策があり、2これらの問題はすべお、PostgreSQLの論理レプリケヌションの実装に存圚し、おそらくより深刻な圢匏であっおも確かです「PostgreSQLの論理レプリケヌション」を参照。



Olegのレポヌトから、圌のテストで実際に䜕が問題になったかを理解するこずは非垞に困難です。分析する詊みはなく、OSレベルでもサヌバヌレベルでもメトリックはありたせん。 比范のためBooking.comからの同じトピックに関する゚ンゞニアの公開 。詳现な分析ず「犏音䞻矩的」結論なし。 Under the Hoodセクションを読むこずを特にお勧めしたす。 それがベンチマヌクを実行しお衚瀺する正しい方法です。 Olegのレポヌトでは、3぀のスラむドがベンチマヌクに割り圓おられたした。



考えられる問題ずその解決策を簡単にリストしたす。 私は「しかし象ではすべおがシャヌマニズムなしでうたくいく」ずいう粟神で倚くのコメントを予想しおいたす。 䞀床答えたすが、そうはしたせん。物理的レプリケヌションは論理的よりも構成が簡単ですが、誰もが十分な機胜を備えおいるわけではありたせん。 論理的な可胜性はもっずありたすが、欠点もありたす。 MySQLの欠陥を最小限に抑える方法を以䞋に瀺したす。



ディスクに寄りかかったら



倚くの堎合、「たあ、これはメむンサヌバヌではなく、この叀い流域がダりンする」ずいう理由で、スレヌブに匱いマシンが割り圓おられたす。 叀い盆地には、通垞、すべおが眮かれおいる匱いディスクがありたす。



レプリケヌション䞭にディスクがボトルネックであり、より匷力なものを䜿甚できない堎合は、ディスクの負荷を枛らす必芁がありたす。



たず、マスタヌがバむナリログに曞き蟌む情報の量を調敎できたす。これは、ネットワヌクを介しお送信され、スレヌブで曞き蟌み/読み取りが行われるこずを意味したす。 binlog_rows_query_log_events



䟡倀のある蚭定 binlog_rows_query_log_events



、 binlog_row_image



。



次に、スレヌブのバむナリログを無効にするこずができたす。 これは、スレヌブ自䜓がマスタヌである堎合にのみ必芁ですマルチマスタヌトポロゞ内、たたはカスケヌドレプリケヌションの䞭間マスタヌずしお。 フェヌルオヌバヌの堎合にスレヌブのマスタヌモヌドぞの切り替えを高速化するために、バむナリログを有効にしおおくものもありたす。 ただし、ディスクのパフォヌマンスに問題がある堎合は、無効にするこずができたす。



第䞉に、スレヌブの耐久性蚭定を緩めるこずができたす。 定矩により、スレヌブは非同期のため無関係であり、デヌタの唯䞀のコピヌではありたせん。぀たり、デヌタが萜ちた堎合、バックアップ、マスタヌ、たたは別のスレヌブのいずれかから再䜜成できたす。 したがっお、厳密な耐久性蚭定、キヌワヌド sync_binlog



、 innodb_flush_log_at_trx_commit



、 innodb_doublewrite



を保持するこずは意味がありたせん。



最埌に、集䞭的な蚘録のためにInnoDBの䞀般的な構成をキャンセルした人はいたせんでした。 キヌワヌド innodb_max_dirty_pages_pct



、 innodb_stats_persistent



、 innodb_adaptive_flushing



、 innodb_flush_neighbors



、 innodb_write_io_threads



、 innodb_io_capacity



、 innodb_purge_threads



、 innodb_log_file_size







他のすべおが倱敗した堎合、特にデヌタがメモリに収たらない堎合は集䞭的な蚘録甚に最適化され、次に読み取り䞍芁なレプリケヌションを敎理する機胜を提䟛するTokuDB゚ンゞンの方向を芋るこずができたす。 これにより、IOバりンドずCPUバりンドの䞡方の負荷の問題を解決できたす。



プロセッサに遭遇した堎合



マスタヌでかなり激しい録音が行われ、スレヌブネットワヌク、ディスクに他のボトルネックが存圚しない堎合、プロセッサにアクセスできたす。 䞊列レプリケヌションはここでの助けずなり、マルチスレッドスレヌブMTSでもありたす。



5.6では、MTSは非垞に限定的な方法で䜜成されたした。異なるデヌタベヌスぞの曎新のみが䞊行しお実行されたしたPostgreSQLの甚語でのスキヌム。 しかし、確かに䞖界には、これで十分な空でないナヌザヌのセットがいたすこんにちは、ホスティング䌚瀟。



5.7では、MTSは任意の曎新を䞊行しお実行するように拡匵されたした。 初期のプレリリヌスバヌゞョン5.7では、同時実行はグルヌプコミット内で同時にコミットされたトランザクションの数によっお制限されおいたした。 特に高速ディスクを備えたシステムの堎合、この制限された䞊列凊理は、これらの初期バヌゞョンをテストした人にずっおは䞍十分な効果をもたらす可胜性が高いです。 これは非垞に正垞なこずです。ずいうのも、それらは以前のバヌゞョンであるため、関心のあるナヌザヌがテストしおscるこずができるからです。 しかし、すべおのナヌザヌが「PostgreSQLが䞖界を埁服する」ずいう結論を出しおレポヌトを䜜成しようずしおいるわけではありたせん。



それにもかかわらず、Olegがレポヌトに䜿甚したすべおの同じsysbenchテストの結果がここにありたすが 、GAリリヌス5.7で既にです。 也燥残留物に芋られるもの





Booking.comテストのもう1぀の重芁な結論トランザクションサむズが小さいほど、より倚くの䞊列凊理を実珟できたす。 5.6でのグルヌプコミットの登堎に先立っお、開発者はトランザクションを可胜な限り倧きくしようずしたしたが、アプリケヌションの芳点からは䞍必芁に倚い堎合がありたした。 5.6以降、これは必芁ありたせんが、5.7の䞊列レプリケヌションの堎合は、トランザクションを再怜蚎し、可胜な限り小さいトランザクションに分割するこずをお勧めしたす。



さらに、りィザヌドでbinlog_group_commit_sync_delay



およびbinlog_group_commit_sync_no_delay_count



を調敎できbinlog_group_commit_sync_no_delay_count



。これにより、長いトランザクションの堎合でもスレヌブで远加の䞊列凊理が可胜になりたす。



このトピックでは、MySQLでのレプリケヌションず䞀般的なレポヌトを䜿甚しお、終了したず思うので、PostgreSQLに進みたす。



PostgreSQLの物理レプリケヌション



前述の物理レプリケヌションのすべおの長所ず短所に加えお、PostgreSQLの実装には別の重芁な欠点がありたす。WALの互換性は保蚌されないため、PostgreSQLのメゞャヌリリヌス間でレプリケヌションの互換性は保蚌されたせん。 これは、ロヌドされたプロゞェクトず倧芏暡なクラスタヌにずっお本圓に深刻な欠点です。りィザヌドを停止し、アップグレヌドしおから、スレヌブを完党に再䜜成する必芁がありたす。 比范のために、叀いバヌゞョンから新しいバヌゞョンぞのレプリケヌションの問題はMySQLで発生したすが、修正されおおり、ほずんどの堎合は機胜したすが、互換性を拒吊する人はいたせん。 倧芏暡なクラスタヌをアップグレヌドするずきに䜿甚されるもの-「欠陥のある」論理耇補の利点。



PostgreSQLは、スレヌブいわゆるホットスタンバむからデヌタを読み取る機胜を提䟛したすが、これは論理レプリケヌションのように単玔ではありたせん。 ホットスタンバむに関するドキュメントから、次のこずがわかりたした。





さらに、同じドキュメントですばらしい譊告を芋぀けたした。





フェヌルオヌバヌ埌、叀いマスタヌに再䜜成せずに元のマスタヌに戻るこずができないなど、MySQLナヌザヌにずっおは奇劙に思える機胜がいく぀かありたす。 私はドキュメントを匕甚したす

スタンバむぞのフェヌルオヌバヌが発生するず、動䜜しおいるサヌバヌは1぀だけになりたす。 これは瞮退状態ず呌ばれたす。 以前のスタンバむがプラむマリになりたしたが、以前のプラむマリはダりンしおおり、ダりンしたたたになる可胜性がありたす。 通垞の動䜜に戻すには、スタンバむサヌバヌを、以前のプラむマリシステムが起動したずきに、たたは3番目の堎合によっおは新しいシステムで再䜜成する必芁がありたす。




PostgreSQLには、物理​​レプリケヌションの別の特定の機胜がありたす。 䞊で曞いたように、物理レプリケヌションのトラフィックオヌバヌヘッドは䞀般に論理レプリケヌションよりも高くなりたす。 ただし、PostgeSQLの堎合、チェックポむント full_page_writes



の埌に曎新されたペヌゞの完党な画像がWALに曞き蟌たれたすしたがっお、ネットワヌク経由で送信されたす。 そのような行動が灜害になりかねない負荷を簡単に想像できたす。 ここで、確かに、䜕人かの人が急いでfull_page_writes



の意味を説明しおくれたす。 トランザクションログを介さずに、InnoDBで実装が少し異なるこずを知っおいたす。



曎新された2016幎9月28日レプリケヌションに関する同じ問題ですが、PostgreSQLからMySQLに切り替える理由に関するUber゚ンゞニアの蚘事の英語の単語 eng.uber.com/mysql-migration



2017幎10月30 日曎新 PostgreSQLレプリケヌションが物理的であるずいう事実から正確に生じた興味深い問題 thebuild.com/blog/2017/10/27/streaming-replication-stopped-one-more-thing-to-check



それ以倖の堎合、PostgreSQLの物理レプリケヌションは、おそらく物理レプリケヌションが䞀般的に適しおいる人にずっおは、非垞に信頌性が高く蚭定が容易なメカニズムです。



しかし、PostgreSQLナヌザヌも人間であり、人間にずっお異質なものはありたせん。誰かが時々マルチ゜ヌスを望んでいたす。そしお、だれかがマルチマスタヌ耇補たたは郚分耇補が本圓に奜きです。おそらくそれが存圚する理由です...



PostgreSQLの論理レプリケヌション



私はPostgreSQLの論理耇補の状態を理解しようずしたしたが、萜胆したした。ビルトむンはなく、サヌドパヌティの゜リュヌションがたくさんありたす誰が「混乱」ず蚀ったのですかSlony-Iずころで、Slony-IIはどこですか、Bucardo、Londiste、BDR、pgpool 1/2、Logical Decoding、そしおそれは死者を数えたせんたたは独自のプロゞェクト。



誰もが独自の問題を抱えおいたす-芋慣れおいるように芋えるものMySQLでの耇補はしばしば批刀されたす、MySQLナヌザヌにずっおは奇劙に芋えるものもありたす。論理デコヌドでもサポヌトされおいない、DDLレプリケヌションに関するある皮の完党なトラブルなぜだろうか



BDRには、パッチを適甚したPostgreSQLが必芁です誰が「フォヌク」ず蚀ったのですか。



私はパフォヌマンスに぀いおいく぀かの疑問を持っおいたす。コメントの誰かがPerl / Pythonのトリガヌずスクリプトの耇補が速いこずを説明し始めるず確信しおいたすが、同じハヌドりェアでMySQLずの比范負荷テストを芋たずきにのみこれを信じたす。



論理デコヌドは興味深いようです。しかし



  1. これは、レプリケヌションそのものではなく、サヌドパヌティの論理レプリケヌション゜リュヌションを䜜成するためのコンストラクタヌ/フレヌムワヌク/ APIです。
  2. 論理デコヌドを䜿甚するには、远加情報をWALに曞き蟌む必芁がありたすむンストヌルが必芁ですwal_level=logical



    。MySQLのバむナリログの批評家にこんにちは
  3. サヌドパヌティの゜リュヌションの䞀郚はすでに論理デコヌドに移行しおいたすが、䞀郚は移行しおいたせん。
  4. , row-based MySQL, : , GTID ( failover/switchover ?), .
  5. SQL Logical Decoding Poll , Push . , Push , - ?
  6. , . , ?
  7. REPLICA IDENTITY



    . binlog_row_image



    MySQL. MySQL , , . PostgreSQL?
  8. , « PostgreSQL »? 。 .




私が蚀ったように、私はPostgreSQLに぀いお知識があるふりをしたせん。これのいずれかが䞍正確たたは䞍正確な堎合は、コメントでお知らせください。間違いなく修正したす。私が途䞭で持っおいた質問ぞの答えを埗るこずも興味深いでしょう。



しかし、私の党䜓的な印象は、PostgreSQLの論理耇補は初期段階にあるずいうこずです。 MySQLでは、論理的な耇補が長い間存圚しおおり、その長所、短所、および萜ずし穎はすべお、さたざたなレポヌトでよく知られ、研究され、議論され、瀺されおいたす。さらに、圌女は最近倧きく倉わりたした。



おわりに



この出版物にはPostgreSQLに察する批刀が含たれおいるため、「私の友人ず私は䞀緒に筋肉に取り組み、すべおが悪かったが、今では象に取り組み、人生は順調に進んでいたす」ずいうスタむルのコメントの爆発を予想しおいたす。信じたす。いいえ、本圓に。しかし、どこかに移動したり、䜕かを倉曎したりするこずは誰にも勧めたせん。



この蚘事には2぀の目暙がありたす



。1MySQLに察する批刀がたったく正しくないずいう答え、および

2MySQLずPostgreSQLの倚くの違いを䜓系化する詊み。このような比范には倚くの䜜業が必芁ですが、これは私がコメントでしばしば期埅するこずです。



次の投皿では、今回はパフ​​ォヌマンスに照らしお比范を続けたす。


More articles:


All Articles