【2080202】iptablesを使用してMySQLのポート転送を行う

リード:1つのインスタンスの上のMySQLリクエストを別のMySQLインスタンスの上に移動します.
ソース・サービス:172.16.3.6:306プライマリ・ライブラリ
ターゲット・サービス:172.16.3.7:306スレーブ・ライブラリ
アクセスアカウント:[email protected]
新旧インスタンスおよび構築主従

ソースサービスの上でポート転送サービスを開く:

shell>> sudo vim /etc/sysctl.conf
vim>> net.ipv4.ip_forward=1 ##           1
shell>> sudo sysctl -p
shell>> sudo /etc/ini.d/iptables start
shell>> sudo iptables -t nat -A PREROUTING -d 172.16.3.6 -p tcp --dport 3306 -j DNAT --to-destination 172.16.3.7:3306
shell>> sudo iptables -t nat -A POSTROUTING -j MASQUERADE 
      sudo iptables -t nat -A POSTROUTING -d 172.16.3.7 -p tcp --dport 3306 -j SNAT -to-source 172.16.3.6
shell>> sudo service iptables save
shell>> sudo service iptables restart

  2. ターゲット・サービス上で3306サービスを開始し、アクセス・アカウントを作成します.

shell>> sudo iptables -A INPUT -s 172.16.3.0/24 -m state --state NEW  -m tcp -p tcp --dport 3306 -j ACCEPT
shell>> sudo service iptables save
shell>> sudo service iptables restart

mysql>> grant select,update,insert,delete on *.* to 'test_01'@'172.16.3.6' identified by 'new_password';
mysql>> flush privileges;
mysql>> \q

ポート転送設定が完了したら、172.16.3.15でアカウントtest_を使用します[email protected]に接続すると、172.16.3.6のiptablesが172.16.3.7のMySQLサービスにリクエストを転送します.このとき接続したアカウントは[email protected]_になりました[email protected]だから私は2歩目に172.16.3.7でアカウントtest_を作成しました[email protected]そして、このアカウントのパスワードとアカウント[email protected]このアカウントのパスワードは一致しています.実際には、test_を作成する必要がなくても、ターゲットサービス172.16.3.7:3106で[email protected]このアカウントは、ソースサービス172.16.3.6:3306でポート転送が完了した後、このインスタンスをオフにすることができる.
  3.まとめ
ビジネス全体の移行では、次のような状況が発生します.
a.古いMySQLインスタンスには複数のビジネスが存在します.
b.古いMySQLインスタンスには長い接続があります.
c.異なる業務では、同じ表に対する修正操作が存在する.
d.すべての業務の接続使用は正確に一致し、すなわちすべてtest@ipこの場合.
      e.binlog_formatはstatement形式ですが、書き込みSQLはnow()と同様の関数を使用しており、プライマリ・スレーブ・データにtableのある時間フィールドのデータが一致しません.
iptablesを転送する目的と欠陥(新旧インスタンスおよび構築主従):
目的:主に、同じテーブルに対する異なるビジネスの変更によるデータの不一致を回避するためです.たとえば、ビジネスAおよびビジネスBは、テーブルtable_01は変更権限があり、test_01の主キーは自増主キーであり、業務挿入時に表示されない挿入主キー値である.業務Aが先に切り替わった時、業務Bはまだ切り替わっていなかったので、この時業務は先にtable_01、それからしばらくしてから業務Bはtable_にデータを挿入する01.この時点で1062プライマリ・キーの競合が発生し、この時点で古いMySQLインスタンスを主とするか、新しいMySQLインスタンスを主とするかが発生します.
欠陥:1.しかし、業務Bが長接続であれば、業務Bを再起動していない場合、業務Bが古いMySQLインスタンスと接続されている場合があり、控訴する場合が発生する可能性があります.2.すべてのビジネスのアカウントが正確に一致しているため、古いインスタンスの上には同じビジネスのusernameがあるが、ipは異なる可能性があり、それらの権限とアカウントも異なる.しかし、iptables転送を使用すると、すべてのアカウントの一致するipアドレスが172.16.3.6に変更されたため、172.16.3.7:3606インスタンスに最後に接続されたアカウントが同じようになったビジネスもありますが、すべてのビジネスのアカウントのパスワードが異なる場合があるという問題があります.このとき、要求を開始するパスワードも異なりますが、172.16.3.7:306に接続されたアカウントはタッチと同じで、1つのアカウントに1つのアカウントのパスワード情報しか対応できません.それでは、すべての業務がパスワードが同じでなければ正常にアクセスできません.パスワードが一致しない要求は拒否されます.
ソリューション:新しいMySQLインスタンスを再起動し、再起動時に--skip-grant-tablesを追加します.すべての業務を切り替えてから、新しいMySQLインスタンスを再起動します.