MaxScale Use Cases
MariaDB MaxScale is a database proxy that extends the high availability, scalability, and security of MariaDB Server while at the same time simplifying application development by decoupling it from underlying database infrastructure.
A server that acts as an intermediary between the client and the database servers, so that the client is not affected by server failures and topology changes.
The act of sending queries to different database servers, so that a single database server does not have to handle all of the load.
The act of configuring a new server to be the primary server when the existing primary fails.
The act of configuring a new server to be the primary server when the operator wants to perform maintenance on the existing primary.
The act of ensuring that interdependent operations maintain consistency by performing the interdependent operations in the same order on all servers.
The act of ensuring causal consistency for read queries by ensuring that all previously committed write queries are applied prior to executing the read query.
When to Use MaxScale
MaxScale is used for different purposes in different kinds of deployments.
Perform automatic failover to a new primary when the existing primary fails.
Perform manual switchover to a new primary to perform maintenance on the existing primary.
Automatically reconnect clients to the new primary after failover or switchover.
Automatically replay transactions on the new primary after failover or switchover.
Enforce causal reads to avoid reading stale data caused by slave lag.
Mitigates effect of primary failure by acting as a Binlog Server.
Filter binary logs for replicas, so that events can be matched, excluded, or rewritten to affect a different database.
Automatically reconnect clients to the new primary node after the existing primary node node fails.
Automatically replay transactions on the new primary node after the existing primary node fails.
Multi-Node Enterprise ColumnStore
Perform query-based load balancing in multi-node deployments.
Perform connection-based load balancing in multi-node deployments.
Receive binary logs containing transactional data.
Filter binary logs, so that events containing transactional data can be duplicated against the analytical ColumnStore databases.