web-dev-qa-db-ja.com

RBRスレーブでグローバルforeign_key_checks = 0

スキーマの例:

CREATE SCHEMA account;
CREATE TABLE `user` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(50) NULL DEFAULT NULL,
    `address` VARCHAR(50) NULL DEFAULT NULL,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB;

CREATE SCHEMA data;
CREATE TABLE `project` (
    `id` INT(11) NOT NULL,
    `account_user_id` INT(11) NOT NULL,
    PRIMARY KEY (`id`),
    INDEX `fk_user` (`user_id`),
    CONSTRAINT `fk_user` FOREIGN KEY (`account_user_id`) REFERENCES 
`accounts`.`user` (`id`)
) ENGINE=InnoDB;

問題の背景

行ベースのレプリケーション(RBR)スレーブがありますが、これには「アカウント」スキーマを含めないでください。 replicate_wild_ignore_table 'accounts'。 '%'を使用して、 'data'スキーマのみが存在するようにします。

唯一の問題は、 "Error_code:1452; handler error HA_ERR_NO_REFERENCED_ROW;"を使用してdata.projectに挿入するとレプリケーションが中断することです。スレーブにaccounts.user.idが存在しないためです。

質問:

この場合、スレーブで「set global set foreign_key_checks = 0 "を永続的に設定することは、適切な修正のようです。私の考えは:

  • 重要な制約は、書き込み/更新が発生するマスターに適用されます。拒否されたステートメントはbinlogに表示されず、スレーブに複製されません。
  • 挿入/更新された各レコードの値は、行ベースのレプリケーションによって明示的に設定されます。 FKが更新を引き起こす場合、それはスレーブに複製される別のbinlogステートメントでキャプチャされます。
  • したがって、スレーブがFK制約をチェックすることについて心配する必要はありません。

私の考えに欠陥はありますか?誰かがこれを試しましたか?私は洞察をいただければ幸いです。

私が検討した他のオプション:

  1. スレーブスキップエラーを設定= 1452

  2. マスターとスレーブ-外部キー制約を削除

    • 理想的ではありません。マスターでデータの整合性を確保したいと考えています。
  3. スレーブ-外部キー制約を削除する

    • また、理想的ではありません。維持するスレーブが複数あり、さらに必要になる場合があります。複数のクロススキーマFKがあり、将来さらに追加する可能性があります。管理が難しくなるのではないかと思います。
1
Mark S

自分の質問に答えるために、スレーブで「set global foreign_key_checks = 0」を試しました。これは機能しませんでした。私のRBR binlogに対して生成されたステートメントは、foreign_key_checks = 1を明示的に設定したためです。

したがって、私はオプション3を試すことができます。

0
Mark S