Routing in production
What to know before an application depends on port 3309 with read routing on, how to let writes through, and what each error means.
Read routing puts DBTrail between your application and its MySQL for reads. This page is what that means on a bad day, and what each error is telling you.
Before production
Read these once before an application depends on this port.
To stop using it, point your application back at your MySQL. To have the copy answer everything again, press Turn routing off on the panel.
It only reads, unless you say otherwise
As it comes, a statement that is not a read is refused with error 1290 and is never sent to your MySQL. To let writes through, set this where DBTrail's settings are, then restart the service that answers the port:
In .env, next to docker-compose.yml:
ROUTER_READ_ONLY=0docker compose up -dIn /etc/bintrail/bintrail-console.env:
BINTRAIL_CONSOLE_ROUTE_READ_ONLY=0sudo systemctl restart bintrail-routerWrites then run on your MySQL as the forwarding user, for anyone who holds the port's password. Give that user exactly the privileges you mean it to have first.
One thing the check cannot see: a SELECT that calls a stored function looks
like a read. If the function writes, your MySQL runs it. The forwarding
user's grants are what stops that.
If something goes wrong
How routing decides
Which statements your MySQL answers and which ones DBTrail's copy answers on port 3309, what the copy cannot answer, what happens when it is busy, and how old the copy is.
Dashboards
Put Metabase, or any tool that runs DuckDB, in front of the Parquet copy. Charts follow the snapshot schedule with nothing to rebuild.