生产环境用Docker部署ProxySQL是否可行？寻求无VIP高可用替代方案

Great questions—let’s break these down one by one, since both touch on critical production-grade deployment and high availability (HA) considerations for ProxySQL.

Absolutely—Dockerizing ProxySQL is a perfectly valid and increasingly common approach for production environments, as long as you address a few key considerations:

• Isolation & Consistency: Docker containers package ProxySQL with its dependencies, ensuring consistent behavior across staging and production. This eliminates "it works on my machine" headaches and makes rollbacks far simpler.
• Orchestration Friendly: If you’re using Kubernetes, Swarm, or another orchestrator, containerized ProxySQL integrates seamlessly with scaling and scheduling workflows. You can spin up additional instances as traffic grows without manual configuration overhead.
• Resource Control: With Docker’s --cpus and --memory flags, you can strictly limit resource allocation to prevent ProxySQL from starving other services on the same host.

That said, don’t overlook these critical production requirements:

• Persistent Configuration: ProxySQL stores runtime config in memory and saves changes to a disk-based file or internal SQLite database. You must mount a persistent volume to this path—otherwise, all config changes will be lost when the container restarts. Example run command snippet:

  docker run -d -v /host/path/to/proxysql/config:/var/lib/proxysql proxysql/proxysql
  

• Network Performance: Docker’s default bridge network adds small latency overhead. For high-throughput environments, use host networking (--network host) or a user-defined bridge with optimized settings to minimize this impact.
• Monitoring & Logging: Ensure container logs are forwarded to your centralized logging system (like ELK or Grafana Loki), and set up metrics collection (ProxySQL exposes stats via a HTTP API or Prometheus endpoint) to track query performance, connection counts, and backend health.
• Stateful vs. Stateless: While ProxySQL can run statelessly with config loaded from a remote source (like a Kubernetes ConfigMap), most production setups require state persistence for runtime rules and backend server lists. Plan for this in your orchestration strategy.

VIP-based HA (like keepalived) is straightforward but adds complexity with network layer configuration and potential single points of failure in the VIP manager. Here are robust alternatives that avoid VIPs:

• Client-Side Load Balancing with Health Checks
  Instead of routing through a single entry point, configure your application clients to connect directly to a pool of ProxySQL instances. Most modern database drivers (e.g., MySQL Connector/Python, JDBC) support built-in load balancing and can be set to skip unhealthy nodes automatically.

  • Pros: Eliminates a centralized proxy layer, reduces latency, and simplifies network setup.
  • Cons: Requires client-side configuration changes, and you’ll need a way to propagate updates to the ProxySQL pool (e.g., via a config service or environment variables).

• DNS Round-Robin + Active Health Checks
  Map a single DNS record to all your ProxySQL instances, and use a health check service (like your cloud provider’s native DNS health checks or a custom script) to remove unhealthy nodes from the DNS record automatically.

  • Pros: No client changes needed (if clients respect DNS TTLs), works with any application stack.
  • Cons: DNS TTLs can cause failover delays, and some clients cache DNS records aggressively, leading to continued connections to unhealthy nodes.

• Service Discovery + Sidecar Proxies
  Use a service discovery tool like Consul or etcd to register healthy ProxySQL instances. Your applications can query the service discovery API to get the current list of active nodes, or use a sidecar proxy (like Envoy) that handles connection routing and health checks on behalf of the app.

  • Pros: Dynamic, scalable, and integrates seamlessly with microservices architectures. Sidecars abstract HA logic away from the application code.
  • Cons: Adds infrastructure complexity (managing the service discovery cluster, sidecar deployment and maintenance).

• ProxySQL Cluster with Peer-to-Peer Sync
  Deploy a cluster of ProxySQL instances where each node syncs its configuration and backend server list with peers (using ProxySQL’s built-in replication or tools like proxysql-admin for Galera clusters). Clients connect to multiple ProxySQL nodes, and if one fails, they fail over to another automatically.

  • Pros: Leverages ProxySQL’s native capabilities, no external tools required. Config changes are propagated across the cluster.
  • Cons: Requires careful configuration to avoid split-brain scenarios, and you still need client-side failover logic or a driver that supports multiple endpoints.

内容的提问来源于stack exchange，提问作者Nicola Strappazzon