Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-4452

Problem with FederatedX between two local MariaDB servers

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 5.5.30, 5.5.40, 10.0.14
    • Fix Version/s: 10.0
    • Component/s: None
    • Labels:
    • Environment:
      CentOS 5.0 64-bit on VMWare ESxi 5

      Description

      I spoke with Sergei at Percona about this issue. I have two MariaDB 5.5.30 (on CentOS 5) servers set up as master-slave (although that should matter, as this is not a replication issue).

      Here is my setup. On the slave, I have a federated table linking back to the master. Also on the slave, I have a batch reporting process that inserts records into a local (slave) table which matches the table definition of the table on the master. When the process is complete, I do a bulk insert like this:

      insert into <federated_table> select * from <local_table>;

      The records are then loaded into the server table, which then flow back to the slave (as well as other slaves) through normal replication.

      The problem is that one time in about 20 (about 5% of the time), I receive the following error on the slave:

      Got error 10000 'Error on remote system: 2006: MySQL server has gone away' from FEDERATED

      Of course, the master is running fine and never hangs or "goes away". When this error occurs, I have my slave reporting code immediately retry the insert query, and it usually works without failure the second time. The two servers are right next to each other and operate on an internal network (10.0.0.x) with just one HP gigabit switch between them. They are both VMWare VMs running in VMWare ESXi 5.

      The master server is a development server, so it is not under any load or contention.

      I'd like to try to find out some more detailed error logging on the slave when this happens with Federated tables or what could be causing this issue.

      Many thanks.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              serg Sergei Golubchik
              Reporter:
              heskin Hank Eskin (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated: