MySQL8.0にある色々なレプリケーションを整理する
技術本部 サービスリライアビリティグループ（SRG）の鬼海（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
なにかの役に立てば幸いです。
レプリケーションとはレプリケーション構成の種類とよくある活用方法多段レプリケーション1:N構成N:1構成非同期と準同期レプリケーションについて非同期レプリケーション準同期レプリケーショングループレプリケーションについてInnoDB ClusterについてInnoDB ReplicaSetについてレプリケーションの種類の機能比較まとめ終わりに
レプリケーションとは
レプリケーションはデータの複製を別のサーバにもてる仕組みです。
MySQLの初期のほうのバージョンから実装されている機能です。
マスターサーバは更新のクエリを受け付けて変更内容をスレーブに転送します。
スレーブはマスターから変更を受け付けますがクライアントからは読み取り専用として利用します。
マスターとスレーブという用語はソースとレプリカという名称に変更されました。
レプリケーション構成の種類とよくある活用方法
レプリケーションは目的によって様々な構成を組むことができます。
多段レプリケーション
通常のマスタースレーブ構成のスレーブがマスターの役割も兼ねる構成です。
孫スレーブとも呼ばれます。
この構成を使う一例としてはMySQLのバージョンアップグレードをローリングで実施するときです。
このような多段スレーブ構成を構築してスレーブをマスターに昇格させることでMySQL5.7にバージョンアップすることが可能となります。
1:N構成
マスター1台に対して複数のスレーブが存在する構成です。
一番オーソドックスな構成となります。
主に参照負荷を分散する目的で利用されます。
スレーブをロードバランサーの仮想VIPでグループ化して、バックアップ目的でユーザ参照のないスレーブを作成することもよくあります。
またマスター障害発生時にスレーブは昇格候補にもなります。
N:1構成
スレーブ1台が複数のマスターのデータを受け付ける構成です。
あまり弊社では利用事例は多くありません。
例えばスレーブをバックアップ専用機としている場合は、1台のスレーブで複数のデータのコピーをもてるのでバックアップ機のサーバ台数を削減することができます。
または、シャーディングで水平分割しているDBを一つのスレーブの同一スキーマ（データベース）に再集約するということも可能です。
非同期と準同期レプリケーションについて
非同期レプリケーションと準同期レプリケーションの2つがあります。
それぞれどこまで更新の同期を保証するかに違いがあり、更新性能やマスタークラッシュ時のデータの永続性に違いがあります。
デフォルトは非同期レプリケーションになっており、一般的なWebサービスであれば非同期で問題はないかとおもいます。
非同期レプリケーション
マスター上のデータとバイナリログの更新は同期を保証しています。
それ以降のスレーブへの伝搬処理については保証しない設定です。
つまりマスターDBがクラッシュした際に、スレーブに伝搬されていないデータが存在する可能性があります。
準同期レプリケーション
マスター上のデータとバイナリログ、および最低1台のスレーブのリレーログへの更新は同期を保証します。最初の1台以外のスレーブについては保証しません。
この動作はMySQL5.5から実装されました。
更新をスレーブ1台のリレーログ更新完了をもって完了とするので、更新のスループットは低下します。
グループレプリケーションについて
MySQL5.7から実装された機能です。
3台以上でグループを構成して全台同じデータを持ちます。
更新を受け付ける「プライマリ」とそれ以外の「セカンダリ」が存在します。
グループレプリケーションではプライマリが1台のみの「シングルプライマリモード」と
すべてのサーバがプライマリになる「マルチプライマリモード」が存在します。
更新SQLを受け付けたプライマリサーバは各サーバのグループコミュニケーションエンジン同士が、サーティフィケーション処理を経てリレーログに書き込みます。
サーティフィケーションは書き込みの競合チェック処理です。
競合したトランザクションではコミットが先に行われた処理だけを成功にし、それ以外をすべて失敗として一貫性を保ちます。
サーティフィケーションまでは同期的に行われ、各ノードのデータへの反映は非同期で行われます。
InnoDB Clusterについて
MySQL5.7から実装された機能です。
MySQL Router + MySQL Shell + グループレプリケーションの組み合わせ構成されます。
MySQL RouterはMySQLサーバへの接続を透過的にルーティングする製品で、
MySQL Shellは様々な機能をもつクライアントです。
グループレプリケーションの機能によってDBの自動昇格や、MySQL Routerの機能によってアプリケーションのDB向き先も自動的に変更することが可能な構成です。
高可用性を重視したい場合に利用が推奨されます。その分更新処理のオーバーヘッドや制約があったりするので事前の検証は必須です。
InnoDB ReplicaSetについて
MySQL 8.0.19から実装された新機能です。
MySQL Router + MySQL Shell + 非同期レプリケーションの組み合わせ構成されます。
この時の非同期レプリケーションはGTID必須です。
参照負荷分散にむいた構成です。
自動のフェイルオーバー機能はありません。
レプリケーションの種類の機能比較
上記で紹介した各レプリケーションの機能比較表です。
いままでの非同期レプリケーション、準同期レプリケーションでは自動フェイルオーバーやアプリからの向き先変更などは別のソリューション（HA ProxyやLB、MHAなど）を組み合わせる必要がありましたが、InnoDB ClusterはMySQLの公式機能のみですべてを補えるようになりました。
しかし、更新時のオーバーヘッドが大きかったりその他制約事項も多いので注意する必要があります。
まとめ
主に非同期レプリケーションだけを利用しているという方が多いかと思いますが、これだけ用途に合わせていろいろなレプリケーションが存在しています。
最適なレプリケーションが選択できるように存在だけでも知っておきましょう。
終わりに
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
