MySQLレプリケーションで使用されるTCP接続のポートと方向性は何ですか？
Mysqlでレプリケーションがどのように機能するか知りたいと思いました。
スレーブとマスターの両方で、ポート3306でmysqlサーバーが実行されています。スレーブはクライアントのように動作し、マスターはサーバーのように動作します。
スレーブがリクエストを送信するためにtcp接続を行うとき、スレーブは常に3306にバインドしますか？応答がサーバーによって送り返されると、destポートは3306になり、スレーブmysqlはそのポートをリッスンしているため、応答を処理しますか？
私の理解が正しいかどうかわかりません。
また、レプリケーションを機能させるために追加する必要がある上りと下りのルールを知ることにも興味があります。
TCPスレーブからの接続の場合、使用可能なポートが選択されますTCPポート、または常に3306ですか？
どんな助けでもありがたいです！
ありがとう！
あなたの仮定は正しくありません。
スレーブしないマスターへのアウトバウンド接続を行うときに3306（またはリッスンしている任意のポート）にバインドし、スレーブがインバウンドクライアント接続を「リッスン」しているポートは、他の点では無関係です。レプリケーション。
スレーブは、ハイポートからマスターのポート（3306など）へのTCP接続を確立し、それ自体を認証し、オプションで少しセッション設定を行います（たとえば、マスターに必要なハートビート構成を通知します）。次に、特定のファイルとバイト位置から開始して、マスターにbinlogストリームを要求します。
マスターは、その位置でbinlogイベントのストリーミングを開始し（有効であると想定）、それらのイベントがマスターで生成されるときに、同じTCP接続を介して新しいbinlogイベントをスレーブに自律的に送信し続けます。マスターneverは、両方のマシンが互いのスレーブである循環レプリケーション構成で、両方のマシンが互いにスレーブでない限り、スレーブに接続を戻します。
スレーブによって開始された単一のTCP接続は、binlogイベントを転送するためのパイプラインであり、マスターは、このTCP接続が確立されていると考える限り、イベントのストリーミングを継続します。何らかの理由で接続が切断された場合、スレーブは、以前と同じプロセスでマスターに再接続し、接続が失われる前に受信した最後の有効なイベントに基づいて、binlogストリームの新しい開始点を要求します。
これまでのサーバーにはserver_idグローバル変数があります。マスターが、すでに接続されているものと同じserver_idで自分自身を識別するスレーブからの接続を受け入れると、マスターは既存の接続を強制的に閉じ、リソースがトラフィックをブラックホールにストリーミングしてリソースをブラックホールに浪費する可能性を防ぎます。マスターに以前の接続（同じスレーブからのはず）がまだ確立されていると思わせるネットワークの問題。
したがって、単一のアクセスリストエントリは、「TCP、スレーブIP、ランダムポートの高い-マスターIP、ポート3306へ」となります（マスターが3306でリッスンしていると想定）。
さらなる詳細：
レプリケーションio_threadは、マスターへのアウトバウンドTCP接続を作成し、その接続を介してレプリケーションイベントを受信し、それらを「リレーログ」（ファイル）に書き込むMySQLのスレッドです奴隷。レプリケーションイベントを「処理」するのではなく、sql_threadで実行するために保存します。
次に、スレーブのsql_threadがio_threadによって書き込まれたリレーログ（ファイル）を読み取り、そこで見つかったイベントを実行します。 SHOW PROCESSLISTの他のクライアントスレッドと同じように見えますが、START SLAVEを実行するとMySQLプロセス内で作成されるスレッドであるため、スレーブのポート3306への接続を介して作成されません。
MySQLプロセス内で実行されているスレッドが同じプロセスへのTCP接続を作成する必要がある理由はありません-スレッドはすでにMySQLサーバー内で実行されており、サーバー内部にアクセスしてレプリケーションイベントを実行しますマスターから受信され、リレーログに保存されます。