Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 487 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MySQL Replication Broken by 18.5.2 and 18.5.3

Stephen Plume

I have a pair of RHEL 8.5 servers - one on a cloud host and one on a server in my office behind a Sophos XG106w.  Both servers running MySQL 8.0.28 as a master/slave pair - the cloud one is the master and the local one a slave for backup purposes.

All worked fine for about a year until I upgraded the XG from 18.5.1 MR1-Build326 to 18.5.2 MR2-Build380.  The replication stopped working.  I've just tried the latest 18.5.3 MR3-Build408 and that also breaks the replication.

The error shown from 'show slave status' in MySQL is:
error connecting to master 'repl@xxx.xxx.xxx.xxx:3306' - retry-time: 60 retries: 1 message: Lost connection to MySQL server during query

There is nothing in the firewall logs for that destination IP address and port.  I have no specific firewall rules on the XG for that destination, it should be covered by a general LAN to WAN any host, any service outgoing one.

An rsync command between the same servers works fine to replicate files, it is only MySQL replication that is broken.

As soon as I switch back to 18.5.1 firmware, it starts working immediately.  

How can I find out what is causing the connection to be lost and then fix it?

Thanks,

Stephen.



This thread was automatically locked due to age.
  • 0

    There is no entry in the Logviewer for this connection? In MR1 as well as MR3? 

    That is very odd. This looks like a normal connection and there should be a connection. Check the Packet capture if you see this particular stream or not?

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Thanks.  Here's what I've tried today.

    On 18.5.1, I created a new firewall rule for just that source/dest/port and put at the top of the list.  Traffic volumes showed on the firewall rules list page.  Nothing logged against that rule number (yes, logging box was ticked), but there were some captured packets between the correct IP addresses.  They're showing NAT ID 0 and Rule ID 0 - which is the default Block All one.  So that doesn't make sense either - replication is working in this configuration.  Rule 0 has logging switched off (can't be edited as far as I can see) - so that might explain why there's nothing in log viewer, but why is it using Rule 0 when traffic is being recorded in the in/out figures against the new rule?

    Rebooted to 18.5.3 and the new rule was lost - presumably configs are saved when the image is loaded.  Recreated it.  MySQL replication error appears as usual.  After a few minutes, traffic volumes in/out show on the firewall rules page as before.  Nothing in log viewer against the new rule again.  Nothing in PCAP either this time.

    I don't understand why it is showing traffic volumes but no logs or packets, nor why on 18.5.1 it is reporting use of rule 0.  I don't have the time to wipe the config and start again, but any other suggestions welcome.

  • 0 in reply to Stephen Plume

    Assuming it actually logs different traffic. If pcap is empty, the firewall does not see the traffic. Pcap (packet capture) is on a interface level. It shows what the firewall actually receives before any kind of firewall rule etc. 

    If you see traffic, it could be a asymmetrical routing. Which means, the SQL Server has another way to communicate to the service and not going through the firewall. 

    That explains why the pcap is empty. 

    firewall rule 0 means basic drop. This could be because the firewall sees traffic, does not match any kind of previous traffic. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Thanks.  When you say not going through the firewall, you mean via a direct path or something?  I can't remember the details of how that part of the XG works - is there any way to log what is not going through the firewall?  Physically there is no other means for these servers to connect other than through the XG.  I've just tried the 19.0.0 upgrade and that also breaks the connection.  Could be time to look for a new firewall.

Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?