federated engine call crashed cluster

Follow

umarzuki

• April 07, 2015 12:45

On a mariadb galera cluster (cluster config v3.5.0), a federated engine call shuts down both mariadb nodes on a 2 nodes cluster + 1 garbd.

The call was originated from a database migrated from mysql 5.5. This issue did not happen on mariadb 5.5.

Any suggestion to resolve this?

I will have to check last recover ID and bootstrap node with latest transaction ID after disabling auto recovery on cmon.cfg

0

• 

  Krzysztof Ksiazek

  • April 07, 2015 14:44

  Hello,

  Can you please share some more details about your setup? What kind of error did you get? What does the table definition look like? What underlying tables look like? Federated engine is not very popular out there and, especially combined with Galera Cluster, bugs may show up. This is, unfortunately, expected for such rare cases.

  Should you wish to move this discussion into more private forum, please open a  support ticket with us.

  0

  Comment actions Permalink
• 

  umarzuki

  • April 08, 2015 03:07

  This is a sample I table I took from mysqldump output

  DROP TABLE IF EXISTS `EVENT_AGENT_CLONE`;
  /*!40101 SET @saved_cs_client     = @@character_set_client */;
  /*!40101 SET character_set_client = utf8 */;
  CREATE TABLE `EVENT_AGENT_CLONE` (
    `event` int(11) NOT NULL,
    `transactionType` varchar(20) NOT NULL,
    `dateCreated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (`event`)
  ) ENGINE=FEDERATED DEFAULT CHARSET=utf8 CONNECTION='mysql://user:pass@ip_address/RemoteDB/EVENT_AGENT';
  /*!40101 SET character_set_client = @saved_cs_client */;
  
  

  0

  Comment actions Permalink
• 

  umarzuki

  • April 08, 2015 03:54

  below are triggers used

   

  BEGIN
  DECLARE counter int;
  
  DECLARE connect_federated_fail CONDITION FOR 1296;
  DECLARE error_reading_packet CONDITION FOR 1158;
  DECLARE connect_federated_timeout CONDITION FOR 1159;
  DECLARE write_packet_timeout CONDITION FOR 1160;
  DECLARE CONTINUE HANDLER FOR connect_federated_fail, connect_federated_timeout,write_packet_timeout,error_reading_packet
    BEGIN
          IF counter=0 THEN
                      DELETE FROM EVENT_AGENT_FAILED WHERE event= new.evdet_id;
                  INSERT INTO EVENT_AGENT_FAILED(event, transactionType) values (new.evdet_id, 'New');
             END IF;
  
    END;
      SET counter = 0;
      DELETE FROM EVENT_AGENT_CLONE WHERE event= new.evdet_id;
      INSERT INTO EVENT_AGENT_CLONE (event, transactionType) values (new.evdet_id, 'New');
      SET counter=1;
  END
  
  
  
  BEGIN
  DECLARE counter int;
  DECLARE connect_federated_fail CONDITION FOR 1296;
  DECLARE error_reading_packet CONDITION FOR 1158;
  DECLARE connect_federated_timeout CONDITION FOR 1159;
  DECLARE write_packet_timeout CONDITION FOR 1160;
  DECLARE CONTINUE HANDLER FOR connect_federated_fail, connect_federated_timeout,write_packet_timeout,error_reading_packet
    BEGIN
      IF counter=0 THEN
          DELETE FROM EVENT_AGENT_FAILED WHERE event= old.evdet_id;
              INSERT INTO EVENT_AGENT_FAILED(event, transactionType) values (old.evdet_id, 'Cancelled');
      END IF;
    END;
  
  SET counter=0;
  DELETE FROM EVENT_AGENT_CLONE WHERE event= old.evdet_id;
  INSERT INTO EVENT_AGENT_CLONE(event, transactionType) values (old.evdet_id, 'Cancelled');
  SET counter=1;
  
  END

  0

  Comment actions Permalink
• 

  Krzysztof Ksiazek

  • April 08, 2015 09:53

  Can you please provide us with error logs from both nodes? Hopefully there'll be some meaningful errors from the crash. I removed user/pass/ip from your post - even if access if firewalled and vpn'ed, it's still better not to post such details in a public internet.

  0

  Comment actions Permalink
• 

  umarzuki

  • April 08, 2015 13:21

  Sorry, I managed to get only log from one node.

  So far, I was told it has been solved by upgrading federated server with identical version.

  0

  Comment actions Permalink

Please sign in to leave a comment.