Du kannst doch einfach die Datenbankverbindung über SSH tunneln. Dann hast du alles, was du brauchst: Komprimierung, Verschlüsselung und Authentfizierung. Außerdem hat das den Vorteil, dass bei der Datenbank ein "localhost" Zugriff ankommt, so dass du die MySQL-Nutzernamen nicht ändern musst.
Ich erlaube mir allerdings, nach dem Sinn zu fragen. Wie viele Daten willst du denn da übertragen, dass du glaubst, komprimieren zu müssen? Der Sinn der ganzen Sache erschließt sich mir überhaupt nicht.
Erstens hast du ja offenbar eh nur 60 Sekunden Bearbeitungszeit auf dem Zielhost. Zweitens übertragen DBMS Daten eh häppchenweise, nämlich normalerweise immer erst genau dann, wenn du mit "fetch_row" den nächsten Datensatz abholst. So groß können die Daten also gar nicht sein, dass Komprimierung erforderlich wäre. Im Zweifelsfall erhöht das nur die Latenz, weil das Protokoll erstmal Wörterbücher bilden muss, um die Daten zu komprimieren und so zwangsläufig mehr im Puffer halten muss.
Wenn du allerdings tatsächlich Daten im GB-Mengen transferieren willst, dann ist Kompression eh der völlig falsche Weg, da sich die Ausbeute in Grenzen hält. Selbst mit unwahrscheinlichen 50% Kompressionsrate bleiben bei 5 GB immer noch 2.5 übrig, was für ein Netzwerk auch genug Last ist.
Bei solchen Mengen ist dann der einzig richtige Weg ein Cluster-System, bei dem auf dem Zielhost ebenfalls ein komplettes DBMS läuft und der Quellhost jede Transaktion sofort weitergibt. Das verteilt das Volumen, auf dem Zielhost treten so gut wie keine Latenzen auf, und die Datenbanken sind trotzdem synchron.
Irgendwie verstehe ich also dein Problem nicht

Imho reicht bei dir eine einfache Datenbankverbindung, die zur Sicherheit über einen SSH-Tunnel läuft, völlig aus. DBMS arbeiten bei solchen Verbrindungen eh inkrementell, die Netzwerklast verteilt sich also.