solidDB Help : High availability
  
High availability
A system that guarantees a high level of continuous service (high availability) generally includes a level of redundancy that enables the system to tolerate failures.
In databases, high availability is usually achieved by using a combination of the following capabilities:
▪ storing and synchronizing multiple copies of each row of a database table (replication),
▪ executing automated recovery routines after failure situations.
solidDB has two separate mechanisms that you can use to build highly available systems, HotStandby and Grid.
In both mechanisms, high availability is enabled by having one or more copies of all successfully written and committed rows of data in other connected database instances. If one database instance is lost (or several instances in a grid-based system), the system can continue to be functional without loss of data. The transition times are designed to be fast, typically fractions of seconds.
▪ HotStandby (HSB) is a mechanism for maintaining a mirrored secondary copy of a database that, if the primary database fails, can instantly continue processing transactions without loss of data. An HSB system always consists of exactly two connected databases. At any time, one of the databases has the primary role and the other has the secondary role.
HSB is designed to provide a fault tolerant system without any impact on application logic. Horizontal scalability is limited to doubling read throughput by distributing the read load to the secondary database instance.
▪ Grid is a mechanism for scaling a system horizontally by adding more nodes to a system. The mechanism distributes the data across servers. Grid data can be configured such that there are always two or more copies of each row of a database table on different servers in the network; C Replicator (CREP) replication is used to keep the data synchronized. As a result, the loss of any individual grid server does not lead to loss of data. A grid is designed to provide theoretically unlimited write and read scalability with some impacts to application logic. In a grid, you enable a fault tolerant system by configuring a replication factor (number of copies of each row of data) of two or higher.
The following diagrams and tables provide a brief overview and comparison of the two mechanisms.
For more information about HSB, see solidDB HotStandby.
For more information about Grid, see solidDB Grid overview.
Diagram that compares HSB and grid architectures
Architecture
 
Category
HSB
Grid
Server count
2
No limit
Replication mechanism
Synchronous replication (by default), however, asynchronous replication is supported by configuration.
Asynchronous replication.
Note Internally, a grid uses C Replicator (CREP) for replication, see C Replicator.
Replication factor
2
Configurable
Fault tolerance mechanism and required components
If a database instance is lost, an external entity is required to manage state transition of the remaining database. solidDB includes the High Availability Controller (HAC) for this purpose, see High Availability Controller.
If a database instance, is lost, grid nodes automatically relocate data to retain the required replication factor. solidDB includes the Node Controller (NC) to manage the restart of the failed database instance, see Node controller, and the Grid Availability Manager (GAM) to maintain the replication factor, see Grid Availability Manager.
Scalability and performance
 
Category
HSB
Grid
Write scalability
Generally the same as for a single server
Some additional performance can be expected if you use relaxed durability with transaction logging, see Durability and logging.
Throughput performance (compared with a single node) can be increased by up to a multiple of the number of nodes in the grid.
Read scalability
Up to twice the throughput performance of a single server, due to being able to route read transactions to the secondary database
Throughput performance (compared with a single node) can be increased by up to a multiple of the number of nodes in the grid.
Capacity limit
Same capacity as a single server
Capacity (compared with a single node) can be increased by up to a multiple of the number of nodes in the grid.
Write latencies
Similar to standalone database
Similar to standalone database
Note Only single row operations are supported.
Read latencies
Similar to standalone database
Similar to standalone database when a query retrieves data from a single node
Application considerations
 
Category
HSB
Grid
SQL limitations
None
Transparent to an application working with a single server system
Limitations for write operations across nodes, see Routing INSERT, UPDATE and DELETE statements
Limitations in procedure and trigger behavior, see Transaction includes a stored procedure
Applications need to be aware of grid SQL limitations
Schema limitations
No schema limitations
Foreign keys not supported
Online software upgrades for solidDB binaries
Supported
Supported
Supported interfaces
ODBC
JDBC
SA
ODBC
JDBC
solidDB utility support
solidDB SQL Editor (solsql)
solidDB Speed Loader (solload)
solidDB Export (solexp)
solidDB Data Dictionary (soldd)
solidDB SQL Editor (solsql)
solidDB Speed Loader (solload)
solidDB Export (solexp)
solidDB Data Dictionary (soldd)
Automatic SQL routing by driver
Yes (ODBC and JDBC)
Yes (ODBC and JDBC)