skysql DR connecting to on-prem maxscale

We'll need a way to reproduce this locally (example table and dataset, Maxscale configuraton etc.) or some profiling information on what is causing the slowness.

markus makela This appears to have been a slight improvement but still lags on binlog replication start

───────────┐

│ Server     │ Address       │ Port │ Connections │ State                                     │ GTID                              │ Monitor         │

├────────────┼───────────────┼──────┼─────────────┼───────────────────────────────────────────┼───────────────────────────────────┼─────────────────┤

│ db1.mfgreg │ 10.90.194.124 │ 3306 │ 0           │ Master, Running, Slave of External Server │ 0-110-64564785,921500-921500-2352 │ MariaDB-Monitor │

├────────────┼───────────────┼──────┼─────────────┼───────────────────────────────────────────┼───────────────────────────────────┼─────────────────┤

│ db2.mfgreg │ 10.90.194.27  │ 3306 │ 0           │ Slave, Running                            │ 0-110-64564785,921500-921500-2352 │ MariaDB-Monitor │

└────────────┴───────────────┴──────┴─────────────┴───────────────────────────────────────────┴───────────────────────────────────┴─────────────────┘

real    0m5.067s

user    0m0.187s

sys     0m0.025s

bbancroft please check the other commands as well, at least maxctrl show maxscale and maxctrl list filters.

The new code now seeks to the GTID position incrementally in the normal replication event processing code. The startup code only finds the file in which the GTID located which is very fast compared to finding the GTID position in the file. The overall performance of the seeking is also improved since the unnecessary tellg() calls were removed in the event handling code while also providing more granular scheduling of work on the worker threads. As a result, the binlogrouter no longer causes any issues with the REST-API while a server is initiating replication from the binlogrouter.