main approaches for deploying ProxySQL are either: - Deploy ProxySQL on your application servers - Deploy ProxySQL in a dedicated layer of servers - Deploy ProxySQL on your application servers and in a separate dedicated layer of servers Each approach has its own advantages and disadvantages.
your underlying infrastructure, there are various implementation methods to implement all three approaches for: - On-premises bare metal servers - Virtualized environments (VMWare, KVM, etc) - Cloud environments (AWS, GCP, Azure, etc) - Containerized environments (Kubernetes, Docker, etc)
is deployed locally • No network overhead • No single point of failure • Isolated configuration • Rolling upgrades 2 • DB monitoring overhead • More backend connections • Configuration effort • Query cache isolated Configuration management is essential QC1 QC2 QC3
is deployed on a standalone server • DB monitoring overhead • Less backend connections • Configuration effort • Shared Query Cache Configuration management is optional Global QC
is deployed on a standalone server • DB monitoring overhead • Less backend connections • Configuration effort • Shared Query Cache Global QC • Additional Round Trip Time • Single point of failure • Shared configuration • No rolling upgrades 2 Configuration management is optional
provided Kubernetes Replicaset, applications connect to one K8s service • Provides load balancing as well as HA • No need for config management, one step deployment / configuration
is deployed locally • No network overhead • No single point of failure • Isolated configuration • Rolling upgrades 2 • DB monitoring overhead • More backend connections • Configuration effort • Query cache isolated Configuration management is essential QC1 QC2 QC3
• Optionally an additional controller pod can be added • ProxySQL instances serving traffic are never configured, they just pull config from the Controller via ProxySQL Cluster • Controller is configured dynamically via SQL, updates are pushed to the pod – config is re-used and persisted in a volume
ProxySQL Cluster can be configured to pull configuration data from a single specific node • Nodes pulling configuration can start with almost zero configuration, just the IP of the controller specified and a short static configuration
ProxySQL Cluster can also be configured to pull configuration data from a set of nodes • The same principle applies as in the previous slide regarding static configuration
ProxySQL can be used to provide HA to itself as it communicates using the MySQL Protocol: • Application layer aware • Provides connection retry • Allows for scale up / scale down without connection loss (during planned maintenance) • Transactions may rollback during edge case unplanned failover
ProxySQL can also be cascaded in a Kubernetes environment, this requires the following: • ProxySQL deployed in the same pod as the application as a separate container, the application then connects to “localhost” • An additional ProxySQL layer is configured using a K8s Service tied to a Replicaset (auto-scale can be implemented) • [Optionally] a ProxySQL Controller pod for the service, this is a ProxySQL instance used ONLY for configuration, traffic ProxySQL instances pull configuration and serve traffic
• ProxySQL is deployed in each application pod and in a ProxySQL service layer • Applications connect to the local ProxySQL server • Provides load balancing as well as HA
• ProxySQL is deployed in each application pod and in a ProxySQL service layer • Applications connect to the local ProxySQL server • Provides load balancing as well as HA
• ProxySQL is deployed in each application pod and in a ProxySQL service layer • Applications connect to the local ProxySQL server • Provides load balancing as well as HA • Open connections are held and retried on an available backend – no connections are lost
• Note: If the PRIMARY MySQL instance is lost while multiplexing is disabled or a transaction is active – a ROLLBACK will occur • ProxySQL is deployed in each application pod and in a ProxySQL service layer • Applications connect to the local ProxySQL server • Provides load balancing as well as HA • Open connections are held and retried on an available backend – no connections are lost