レプリケーションは、バイナリログ内のデータベースに対するすべての変更 (更新、削除など) を追跡するソースサーバーに基づいています。 バイナリログは、サーバーが起動した瞬間からデータベースの構造または内容 （データ） を変更するあらゆるイベントが書き込まれた記録として機能します。 SELECT ステートメントは通常、データベースの構造および内容を変更しないため記録されません。

ソースに接続する各レプリカは、バイナリログのコピーを要求します。 つまり、ソースがレプリカにデータをプッシュするのではなく、ソースからデータをプルします。 レプリカは、受信したバイナリログからもイベントを実行します。 これは、元の変更をソースで行ったときと同じように繰り返す効果があります。 テーブルが作成されるか、その構造が変更され、元のソースで行われた変更に従ってデータが挿入、削除および更新されます。

各レプリカは独立しているため、ソースバイナリログからの変更のリプレイは、ソースに接続されている各レプリカで独立して行われます。 また、各レプリカはソースからのリクエストによってのみバイナリログのコピーを受信するため、レプリカは独自のペースでデータベースのコピーを読み取って更新でき、ソース側またはレプリカ側の最新のデータベースステータスに更新する機能に影響を与えることなく、レプリケーションプロセスを任意に開始および停止できます。

レプリケーション実装の仕様に関する詳細は、セクション17.2.3「レプリケーションスレッド」を参照してください。

ソースサーバーおよびレプリカは、レプリケーションプロセスに関するステータスを定期的にレポートして、それらを監視できるようにします。 すべてのレプリケーション関連ステータスの説明については、セクション8.14「サーバースレッド (プロセス) 情報の確認」を参照してください。

ソースバイナリログは、レプリカが処理される前に、レプリカ上のローカルリレーログに書き込まれます。 また、レプリカは、現在の位置に関する情報をソースバイナリログおよびローカルリレーログとともに記録します。 セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」を参照してください。

データベースの変更は、イベント評価を制御する様々な構成オプションおよび変数に従って適用される一連のルールに従ってレプリカでフィルタ処理されます。 これらのルールがどのように適用されるかについての詳細は、セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。