On Dec 19, 2008, at 4:41 PM, Rick Gutleber wrote:
> I don't know if this is really a MySQL++ question or a MySQL question.
There's no networking code at all in MySQL++. That's all entirely up
to the C API library. However:
> when the poller has been rebooted, reconnecting always fails with
> MySQL error 111 ("Connection refused") or 113 ("No route to host")
I've learned over the years to trust that these indicate a real
problem which isn't likely to be something the C API's networking code
can fix.
The first error says there's no service listening on that port on the
remote peer. Don't treat this as a permanent condition; try again
later, after giving mysqld time to start and initialize.
The second error indicates that the machine isn't fully rebooted yet,
or perhaps there's some confusion in the ARP, switch or routing tables
due to dynamic addressing. It means the low-level ARP and IP routing
mechanisms tried to find a way to talk to the host and failed. Unless
you're exacerbating the problem with dynamic addressing, the solution
is the same: try again later. If you're using DHCP + DNS to find the
remote hosts, don't; they're servers, so they need static addresses.
> It won't work until I start the app over again.
Are you certain that this isn't just masking the fact that you're
trying again later?
> Does anyone know if there is something I can do to correctly
> "reinitialize" things so the app can reconnect without being
> restarted.
If it does turn out that you need to completely blow away all MySQL++
and MySQL data structures and start over, you can send some kind of
signal to the app to tell it to restart. On *ix type boxes, the
SIGUSR1 and SIGHUP signals are commonly used for this. You could also
twiddle a semaphore, or send some kind of IPC message.