You can implement database clustering by using solidDB Grid. For an overview of the solidDB Grid architecture, see solidDB Grid architecture.
Logically, the grid is like a traditional relational database, where user data is stored in tables (on-disk, in-memory, or both) that are operated by using SQL. See Data storage in solidDB.
The basic building block of a grid is a node; a solidDB server with built-in table partitioning, replication, and availability management support. There are no special arbiters, routers, or configuration servers. The grid nodes can be installed in the cloud, or on physical servers, or a mixture of both locations. For more information, see Grid nodes.
Client applications connect to the grid by using grid-aware drivers or by using utility tools. The grid splits application data into multiple partitions and maintains multiple copies of each partition to provide scalability and high availability, see Table partitioning.
A grid manages both the replication of application data and the replication of the grid metadata, see Grid replication.
When working with databases and other files in a grid, you should be aware of the following principles.
All nodes in a grid share the same database schema
In a grid node, the database schema consists of regular database elements (such as tables, indexes, stored procedures), and other regular database definitions that are added with grid configuration-specific definitions (such as replication maps, table type definitions and grid node definitions).
All grid nodes share the same schema, which is updated and approved by the majority of grid nodes. Grid nodes cannot have any schema elements that are not part of the grid schema.
Most general database design patterns are applicable when using a grid but there are various design principles that must be taken into account when a schema is designed for a grid; for more details, see Schema requirements and recommendations.
One node in the grid is the grid leader
The grid leader performs a number of tasks on behalf of all grid nodes:
▪ manages grid configuration changes and database schema changes,
▪ monitors the responsiveness of the grid nodes,
▪ makes sure that data is distributed evenly across the grid.
The grid nodes use a consensus algorithm to determine which node is the grid leader, see solidDB consensus algorithm.
You can create both partitioned and non-partitioned tables in a grid
▪ A partitioned table is split into multiple partitions, which are distributed between the grid nodes; each partition contains a subset of the data. For more detail about partitioned tables, see Table partitioning.
▪ A non-partitioned (shared) table is a standard solidDB table. The table is replicated to every node regardless of how many nodes there are in the grid. All write operations are performed on a single node.
A transaction log is specific to an individual grid node
Grid nodes contain database files and transaction log files that belong together. Mixing log files and database files from other grid nodes leads to errors when log files are being read. A clear directory structure or naming pattern is recommended for processing backups.
You cannot move a grid by simply copying the grid files
In addition to containing data and metadata about database tables, indexes, and stored procedures, a grid database file contains configuration information and the network addresses of grid nodes. Hence, just copying grid files to a similar set of nodes in other machines is not sufficient to start the grid in a new location.
Generally, you should not force a query to execute on a specific node
When you run an SQL query against the grid, you should usually let the server or the grid-aware ODBC or JDBC driver route the statement to the appropriate node. It is possible to force the query to execute on a specific node, but that is not advisable unless you know and understand how data is partitioned in the current grid.
However, executing admin commands on a specific node might be appropriate. For example, you might use an admin command to turn on a trace or request a report from a specific grid node.
Distributed transactions are used to access more than one grid node
Any operation (statement or transaction) that needs to access more than one grid node is a distributed transaction.
▪ Distributed reads: By default, when a SELECT statement is executed in a server and the server determines that rows that meet the WHERE criteria might be found in multiple grid nodes, the relevant part of the query is routed to the other nodes in the grid.
If required, you can force a read operation to run only on the local grid node, see SET GRID READ.
▪ Distributed writes: Distributed write transactions are not supported.
– In a transaction where an individual statement attempts to write to two different nodes, the statement fails but the transaction survives.
– In a transaction where different statements write to different grid nodes, the first write operation defines the grid node where the write operation is allowed. Write operations to any other grid node fail.
The only supported isolation level is READ COMMITTED. For other isolation levels, an error is returned when a distributed read operation is executed. For more information about isolation levels, see Controlling transaction isolation levels.
For more information about routing data in a grid and the expected success or failure of statements, see Routing data in a grid.