まず、エラーメッセージ
次のように変更を加えるために、フィールドtest.test_tab_t1に関する最近のシステムのアップグレードプロジェクトの同僚は、SQL文は次のとおりです。
ALTER TABLE TEST.TEST_TAB_T1 MODIFY BXXX VARCHAR（200）。
MySQLのプロジェクト内のマスタ・スレーブ同期エラー、表示され、システムのアップグレードを行った後、次のように、エラーメッセージは次のとおりです。
MySQLの>ショースレーブステータス\ G MASTER_LOG_FILE：binlog.000233 Read_Master_Log_Pos：274415020 RELAY_LOG_FILE：リレー-bin.000253 RELAY_LOG_POS：175535154 のRelay_Master_Log_File：binlog.000233 Slave_IO_Running：はい Slave_SQL_Running：いいえ .............. ...： Last_Errno：1677 LAST_ERROR：テーブル'test.test_tab_t1'の列28は、型から変換することができない'VARCHAR（30）（バイト））'と入力する'のvarchar（400（バイト）GBK）' Skip_Counter：0 Exec_Master_Log_Pos： 175536357 Relay_Log_Space：274410464
エラーメッセージのMySQLのアラームログ：
2020-03-24T16：53：16.051244Z 11686 [ERROR]チャネルに対するスレーブSQL ''：テーブルの列28 'test.test_tab_t1はVARCHAR（30（バイト））'型から変換できない'はVARCHAR'を入力する「（400 （バイト）GBK）」、ERROR_CODE：1677 2020-03-24T16：53：クエリを実行している16.051269Z 11686 [ERROR]エラー、スレーブSQLスレッドが中止されました。問題を修正し、「SLAVE START」とスレーブSQLスレッドを再起動します。私たちは、ログ「binlog.000233」位置175536357で停止しました。
第二に、環境情報
プロジェクトのコミュニティMySQLバージョン5.7.24の文字セットが使用することです：GBK、バイナリログは+ keepalivedのデュアルマスター（マスター・マスター）アーキテクチャを使用して、ROW形式です。
MySQLの> @@バージョン、@@ character_set_server、@@ binlog_formatを選択します。 + ----------- + ------------------------ + ------------ ----- + | @@バージョン| @@ character_set_server | @@ binlog_format | + ----------- + ------------------------ + ------------ ----- + | 5.7.24 | GBK | ROW | + ----------- + ------------------------ + ------------ ----- +
第三に、診断処理
1は、エラー1677でMySQLのレプリケーションのブレークに応じて表の列..「...」、与えられた文書の用語分析情報err1677ビューtest.test_tab_t1テーブルのカラム（列28）の（ドキュメントID 2037712.1）変換することはできません文字セット変換エラーにそこに関連しています。
最初の比較（MASTER1-マスター2）文字セットの情報：
比較後（MASTER1、MASTER2）データベース、テーブル、列レベル文字セット情報：
MASTER1データベース、テーブル、カラムレベルのキャラクタセットの情報：
MySQLの> information_schema.schemataから選択*どこSCHEMA_NAME = 'テスト'; + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH | DEFAULT_ENCRYPTION | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | デフ| テスト| GBK | gbk_general_ci | NULL | NO | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + TABLE_NAME 'はtest_tab_t1' = MySQLの>を選択TABLE_SCHEMA、TABLE_NAME、TABLE_TYPE、INFORMATION_SCHEMA.TABLESからTABLE_COLLATION。 + -------------- + ------------ + ----- ------- + ----------------- + | TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | TABLE_COLLATION | + -------------- + ------------ + ----------- - + ----------------- + | テスト| test_tab_t1 | ベーステーブル| gbk_chinese_ci | + -------------- + ------------ + ------------ + -------- --------- + MySQLの>を選択TABLE_NAME、COLUMN_NAME、CHARACTER_MAXIMUM_LENGTH、CHARACTER_OCTET_LENGTH、CHARACTER_SET_NAME、COLLATION_NAME table_nameは= information_schema.columnsから'test_tab_t1'およびTABLE_SCHEMA = 'テスト'とORDINAL_POSITION = 29。 + ------------ + ------------- + ---------------------- ---- + ------------------------ + -------------------- + ---------------- + | TABLE_NAME | COLUMN_NAME | CHARACTER_MAXIMUM_LENGTH | CHARACTER_OCTET_LENGTH | CHARACTER_SET_NAME | COLLATION_NAME | + ------------ + ------------- + ---- ---------------------- + ------------------------ + - ------------------ + ---------------- + | test_tab_t1 | BXXX | 200 | 400 | GBK | gbk_chinese_ci | + ------------ + ------------- + ---------------------- ---- + ------------------------ + -------------------- + ---------------- +
MASTER2データベース、テーブル、カラムレベルのキャラクタセットの情報：
MySQLの> information_schema.schemataから選択*どこSCHEMA_NAME = 'テスト'; + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH | DEFAULT_ENCRYPTION | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | デフ| テスト| GBK | gbk_general_ci | NULL | NO | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + TABLE_NAME 'はtest_tab_t1' = MySQLの>を選択TABLE_SCHEMA、TABLE_NAME、TABLE_TYPE、INFORMATION_SCHEMA.TABLESからTABLE_COLLATION。 + -------------- + ------------ + ----- ------- + ----------------- + | TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | TABLE_COLLATION | + -------------- + ------------ + ----------- - + ----------------- + | テスト| test_tab_t1 | ベーステーブル| gbk_chinese_ci | + -------------- + ------------ + ------------ + -------- --------- + MySQLの>を選択TABLE_NAME、COLUMN_NAME、CHARACTER_MAXIMUM_LENGTH、CHARACTER_OCTET_LENGTH、CHARACTER_SET_NAME、COLLATION_NAME table_nameは= information_schema.columnsから'test_tab_t1'およびTABLE_SCHEMA = 'テスト'とORDINAL_POSITION = 29。 + ------------ + ------------- + ---------------------- ---- + ------------------------ + -------------------- + ---------------- + | TABLE_NAME | COLUMN_NAME | CHARACTER_MAXIMUM_LENGTH | CHARACTER_OCTET_LENGTH | CHARACTER_SET_NAME | COLLATION_NAME | + ------------ + ------------- + ---- ---------------------- + ------------------------ + - ------------------ + ---------------- + | test_tab_t1 | BXXX | 200 | 400 | GBK | gbk_chinese_ci | + ------------ + ------------- + ---- ---------------------- + ------------------------ + - ------------------ + ---------------- +
問題がある）;ドキュメント（（ドキュメントID 2037712.1）の外観によると、実際にシステムのアップグレード列（ALTER TABLE MODIFY TEST.TEST_TAB_T1 BXXX VARCHAR（200）テーブルのフィールドに対応を変更します。
报错：LAST_ERROR：テーブル 'test.test_tab_t1' の列28は、型から変換することができない 'VARCHAR（30（バイト））'「VARCHARを入力する（400（バイト）GBK）
Test.test_tab_t1テーブルのフィールドが変更されbxxx（ORDINAL_POSITION = 29）文字セットの問題は、コピー処理中に登場し、GBKは、変更が本当にbxxx VARCHAR（16）の前に、サイズは2バイトです。
CHARACTER_SET_NAMEは'GBK' = information_schema.character_setsからのmysql> SELECT * FROM。 + -------------------- + ---------------------- + ----- ------------------- + -------- + | CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | DESCRIPTION | MAXLEN | + -------------------- + ---------------------- + ----- ------------------- + -------- + | GBK | gbk_chinese_ci | GBK簡体字中国語| 2 | + -------------------- + ---------------------- + ----- ------------------- + -------- +
しかし、文字セット（MASTER1、MASTER2）データベース、テーブル、カラム・レベルの情報を比較することは同じであり、一貫性のない文字セットの問題は存在しません。そして、問題はそれほど単純ではないと感じ、その後、ダウン分析しました。
環境は、それが両方のインスタンスが同時にこの文を実行しているかどうかを、ダブルマスターであるので、私は、私たちは担当者が仕様に従って動作するように実装するかどうかについて考え始め、character_set_client内部のセットな/etc/my.cnfクライアントのトラブルシューティング中に発見されましたMASTER1にUTF8で、MASTER2にGBKされます。私たちは、障害のbinlog時間内の、binlog.000233でエラー、ストップは175 536 357である位置の情報ポイントを見てみて。
mysqlbinlogは--no-デフォルト--start位置= 175536357 --database =試験/opt/mysql/log/binlog/binlog.000233 --verbose ＃175536357で ＃200325午後十二時53分16秒サーバID 1 end_log_pos 175536422 CRC32 0xddd5d37 Anonymous_GTIDがlast_committed = 271185 SEQUENCE_NUMBER = 27186 rbr_only = YES / * 50718のSET TRANSACTION ISOLATION LEVEL READ COMMITTEDが* // * * /！！; ！SET @@ SESSION.GTID_NEXT = 'ANONYMOUS' / * * /; ＃175536422で ＃200325午後12時53分16秒、サーバID 1 end_log_pos 175536505 CRC32 0x3799f3bクエリなthread_id = 14154792 EXEC_TIME = 0 ERROR_CODE = 0 SET TIMESTAMP = 1585068796 / * * /！; ！SET @@ session.pseudo_thread_id = 14154792 / * * /; SET @@ session.foreign_key_checks = 1、@@ session.sql_auto_is_null = 0、@@ session.unique_checks = 1、@@ session.autocommit = 1 / * * /！; SET @@ session.sql_mode = 1075838976 / * * /！; SET @@ session.auto_increment_increment = 2、@@ session.auto_increment_offset = 2 / * * /！; ！！/ * \ C GBK * // * * /; SET @@ session.character_set_client = 28、@@ session.collation_connection = 28、@@ session.collation_server = 28 / * * /！; SET @@ session.lc_time_names = 0 / * * /！; ！SET @@ session.collation_database = DEFAULT / * * /; BEGIN ！/ * * /; 175536505で＃ `番号23434にマッピングtest`.`test_tab_t1`：＃200325夜12時53分16秒サーバID 1 end_log_pos 175536685 CRC32 0xe3db6b6b Table_map 175536685で＃ ＃200325夜12時53分16秒サーバIDが1 end_log_pos 175537481 CRC32 0xf1343123 Update_rows：テーブルID 2334個のフラグ：STMT_END_F ### UPDATE `test`.`test_tab_t1` ### ### @ 1 = '........' ### .......... ### @ 29 = '........' ### ...... ### @ 40 = '...' ### SET ### @ 1 = '........' ### ...... ### @ 29 =」.... .... ' ### ...... ### @ 40 =' ...」
ビンログは、SETの内部@@ session.character_set_client = 28、@@ session.collation_connection = 28、@@ session.collation_server = 28文字セットは確かにある参照GBK
MySQLの> ID = 28 information_schema.collationsから選択*; + ---------------- + -------------------- + ---- + ------ ------ + ------------- + --------- + --------------- + | COLLATION_NAME | CHARACTER_SET_NAME | ID | IS_DEFAULT | IS_COMPILED | SORTLEN | PAD_ATTRIBUTE | + ---------------- + -------------------- + ---- + ------ ------ + ------------- + --------- + --------------- + | gbk_chinese_ci | GBK | 28 | はい| はい| 1 | PADのSPACE | + ---------------- + -------------------- + ---- + ------ ------ + ------------- + --------- + --------------- + 1行目のセット（0.01秒）
十分な文字セットよりも確かに多くは原因矛盾するものではありません。だから、公式の推奨される方法を使用して、アドレスにパラメータslave_type_conversions = ALL_LOSSY / ALL_NON_LOSSYを設定するには有効ではありませんが、この方法はまた、失われたデータ変換のリスクです。
さらにまた、パケットからコピーされたフィールドのメインキャラクターが矛盾エラーの問題をerr1677が、また別の場合、binlog_format = ROWを言及記載に従ってhttps://bugs.mysql.com/bug.php?id=83461リレーログを解析する解析する問題は、あなたがbinlog_format = MIXED形式を考慮することができるので、スレーブはプルアップすることができません引っ張ってみてください。
この分析では、私は考え、それが情報を見つけるために続けて、時々このように感じていない、山の貧しい水の複合体は銀の裏地を持っています。これはによって破壊5.6.37、行ベースのマスター・マスター・レプリケーションのバグ＃88595で、//bugs.mysql.com/bug.php ID = 88595します。https：最後に、私は非常に代表的な言及を見つけましたか？列を追加または列をドロップします。しかし、プロジェクト環境ではアーキテクチャがbinlog_format = ROWダブル修士で、5.7.24です。
私が投稿binlogの情報を対比し、中断から時間的に上記の表の更新test.test_tab_t1ポイントの存在を行います。ここで私は一貫性のないバージョンが、合格言うが、症状に応じてすることはほとんどあります。
アルゴリズムは、より低いINPLACE（デフォルト）=。
MASTER1が行わ：ALTER TABLE TEST.TEST_TAB_T1 MODIFY BXXX VARCHAR（200）;プレス記録バイナリログに、
ここで、変更フィールド情報MASTER2同期文、動作中に、同時にバイナリログ（完全にフィールドステートメントの変化の割合）を引くことによって更新test.test_tab_t1 MASTER2テーブルの存在
MASTER1は、あなたが更新ステートメントtest.test_tab_t1テーブルを同期するとき、それはフィールドを変更したように、テーブル構造が変更された、との情報更新文または元の構造は、そのerr1677の誤差がありました。
基本的に渡すが、ここでは二つの質問があり、1が唯一の解釈、同僚の実装（MASTER1）、この事業は、単なる一例を書き込むように構成されていない二重の書き込みである非書き込みの例について実施DDLアクション。データベースは、5.6からのアップグレードに基づいており、そこに問題のバージョンがあり、後の彼の同僚のプロジェクトの実施に相談します。レア...？レア...？現在の容量、最初のレコード、その後、より詳細なフォローアップ分析を制限しました。
第四に、ソリューション
ここでは、このような状況のない参照溶液はありません私のためであり、上記の分析の後、テーブルのビジネスの状況に基づいて、データの整合性を確認した後、エラーをスキップすることを決めました。
スレーブを停止します。
手段スキップステップ＃エラー、デジタル可変バック、ステップ1をスキップ表します
設定されたグローバルSQL_SLAVE_SKIP_COUNTER = 1。
スレーブを起動します。
PT-テーブルチェックサムは、修復するために、このツールの使用に矛盾がある場合、試験test_tab_t1テーブルのデータの整合性MASTER1、MASTER2データベースを検出するために使用することができます。
PT-テーブル・チェックサム--nocheck複製・フィルタ--databases =テスト--replicate = test.test_tab_t1 --create-複製・テーブル--host = xxxは--port 3306 -uroot -pxxx
第五に、失敗の概要
故障解析とプロセスのトラブルシューティングの上に、我々は、私はオラクルのGoldenGateでのみDMLをコピーすると思いますので、DDLのソーステーブルは、OGG-01161交換し、OGG-01163は非常に似て、そのバグを発見しました。
多くのオンラインOGG-01161、テーブル構造の変更がreplicatプロセスの異常終了の記事につながるOGG-01163ソースは、ソースとターゲット側、Rの再起動プロセスやエラーの同じテーブル構造の比較を参照しています。
フィールドの送信元と宛先エンドの長さを変更し、DEFファイルが変更されますが、が、トレイルで生成されたメタ情報ファイルが更新されません。replicatは、デフォルトのプロセスメタ情報証跡ファイルに従ってください。だから、それはまだエラーです。の跡をカバーするために新しいDEFコンテンツのメタ情報を追加するためのオーバーライド・オプションの必要性。
DDLはMASTER1テーブルのメタ情報に同期する前に変更する前に、この場合は、更新ステートメントの類似したマスター2の障害があるされるようにエラーがあるだろうそうすることを、変更、およびテーブルのメタ情報の構造の後に、すでに多くのMASTER1されます。
物事は本当に連結している、データベースも例外ではありません。