Skip to content
  • Nuno Carvalho's avatar
    f13005c4
    BUG#24818604: MYSQLD CRASHES WHILE STARTING GROUP REPLICATION FOR A NODE IN RECOVERY PROCESS · f13005c4
    Nuno Carvalho authored
    During BUG#24818604: MYSQLD CRASHES WHILE STARTING GROUP REPLICATION
    FOR A NODE IN RECOVERY PROCESS analysis, three issues were found:
     1) Foreign keys were not being ignored when foreign_key_checks == 0
        That was fixed on BUG#24916351: GR KEY GENERATION FOR FOREIGN
        KEY SHOULD BE IGNORED IF PARENT IS NOT YET CREATED
     2) Foreign keys referenced_key_name could be NULL when a DELETE on
        a child table was executed before accessing the parent, like
        just after server start.
        That was fixed on BUG#25126722 FOREIGN KEY CONSTRAINT NAME IS
        NULL IN INFORMATION_SCHEMA AFTER RESTART
     3) A DELETE on child table after the parent table was dropped using
        foreign_key_checks= 0, is making referenced_key_name NULL and
        consequently crashing the server.
    
    This patch solves issue 3), by skipping foreign keys inclusion on
    transaction write set if referenced_key_name is NULL, since this,
    after issue 1) and 2) fix, means that the parent table does not
    exist and there is no foreign key constraint.
    
    (cherry picked from commit 3160ccf71a0b6fd1d5d87d4ce63c9477f5626e44)
    f13005c4
    BUG#24818604: MYSQLD CRASHES WHILE STARTING GROUP REPLICATION FOR A NODE IN RECOVERY PROCESS
    Nuno Carvalho authored
    During BUG#24818604: MYSQLD CRASHES WHILE STARTING GROUP REPLICATION
    FOR A NODE IN RECOVERY PROCESS analysis, three issues were found:
     1) Foreign keys were not being ignored when foreign_key_checks == 0
        That was fixed on BUG#24916351: GR KEY GENERATION FOR FOREIGN
        KEY SHOULD BE IGNORED IF PARENT IS NOT YET CREATED
     2) Foreign keys referenced_key_name could be NULL when a DELETE on
        a child table was executed before accessing the parent, like
        just after server start.
        That was fixed on BUG#25126722 FOREIGN KEY CONSTRAINT NAME IS
        NULL IN INFORMATION_SCHEMA AFTER RESTART
     3) A DELETE on child table after the parent table was dropped using
        foreign_key_checks= 0, is making referenced_key_name NULL and
        consequently crashing the server.
    
    This patch solves issue 3), by skipping foreign keys inclusion on
    transaction write set if referenced_key_name is NULL, since this,
    after issue 1) and 2) fix, means that the parent table does not
    exist and there is no foreign key constraint.
    
    (cherry picked from commit 3160ccf71a0b6fd1d5d87d4ce63c9477f5626e44)
Loading