Dynamic Load Balancing
Just as a web load balancer intercepts HTTP requests, and in turn, distributes the requests across multiple web servers, iDB intercepts, and distributes SQL Queries coming from web/application servers across multiple database servers. Find out more from a real world use case at KixEye
iDB provides Clustering and Dynamic Load Balancing without any database engineering on app or database servers
- Reduced database downtime with High-Availability
- Automatic read/write split for instant scale out
- Replication aware dynamic load balancing
- Authentication offload & Connection Pooling
- Surge Queue protects servers under high load
- Query Routing and Sharding
iDB enables high availability for the data tier, just as the web load balancers (ADCs) have enabled for the web tier. Upon the occurrence of a database server failure, iDB switches client connections to a live database server seamlessly. A single cluster can incorporate database servers from different datacenters connected via a secure IP tunnel in order to reduce application downtime.
iDB transparently routes all write queries to master/primary servers, and read queries to slave servers, helping even non-cluster-aware applications utilize multiple servers and increase performance and availability. iDB being a total SQL proxy can perform read/write split for queries and stored procedures achieving instant scale out, without application modifications.
Replication Aware Load Balancing
iDB can balance and traffic shape database load across two or more servers using a specialized Dynamic Load Balancing algorithm that utilizes the available database capacity more efficiently. iDB monitors query responses in real-time, hence it can predict which server would respond faster to queries in the next second, and distribute load accordingly. iDB supports all possible replication topologies used by MySQL,SQL Server and Orcale, be it Master-Slave, Multi-Master, Multi-Master-Multi-Slave, Percona xtraDB Galera, NDB cluster, Peer-2-Peer, log-shipping, SQL mirroring, Always-on, Oracle RAC, or even shared disk databases. iDB is replication technology agnostic.
Authentication offload & Connection Pooling
Database servers can benefit from keeping SQL connections alive especially for a LAMP stack where queries results in creating, authenticating, using and destroying many SQL connections. A lot of resources and time is saved by iDB connection pools as the process for accepting a connection, and authenticating the same isn’t required for each query anymore. iDB re-uses existing connections, and even multiplexes many client connections into a few SQL connections, thereby reducing connection load on a database server, and allowing a lot more web/app servers to work with the same set of database servers without running out of connections and giving errors.
SQL Surge Queue
iDB allows users to regulate the maximum peak concurrent load a SQL database and prevent the server from getting overloaded. iDB’s surge queue provides a QoS like effect, without which the servers could get overloaded with excess connections, become slow on a per query response, and eventually crash servers. The SQL surge queue prevents the server issues from happening, and lets users ride out peak loads more effectively.
Query Routing and Sharding
iDB also can provide for sharding of the databases with all the sharding rules residing on iDB as simple regex rules, without having the applications involved. The sharding/routing rules can be updated live in production to allow for more shards. Query routing can be used to send reporting workload to specific servers away from production servers and prevent unintentional production service outages.