Grid setup and management

A grid is a set of replication servers that are configured to simplify administration. When you run SQL data definition statements from within a grid context on a grid server, the statements propagate to all servers in the grid. You can run SQL data manipulation statements and routines through grid routines. You can choose to set up replication automatically when you create a table through a grid. You can propagate external files to other servers in the grid.

SQL statements are not replicated by Enterprise Replication. Enterprise Replication replicates the row images that are the results from SQL statements. The grid propagates SQL statements, but does not, by default, propagate the results of propagated SQL statements. The following illustration shows three replication servers, named Cdr1, Cdr2, and Cdr3, that replicate row images between each other, while the grid propagates SQL statements and administration commands.

Figure 1: Replication of rows as a grid propagates SQL statements to each server.

This image shows that replication servers replicate row images between each other and the grid propagates SQL statements to each of the servers.

A grid can be useful if you have multiple replication servers and you often perform the same tasks on every replication server. The following types of tasks can be run through the grid:

  • Creating replicated tables. When you create a replicated table through a grid, the other tasks for setting up replication are completed automatically: a replicate is created for the table, participants are defined for each replication server, and the replicate is added to the grid replicate set.
  • Administering servers, for example, adding chunks, removing logical logs, or changing configuration parameter settings
  • Updating the database schema, for example, altering, adding, or removing tables
  • Running or creating stored procedures or user-defined routines
  • Updating data, for example, purging old data or updating values that are based on conditions
  • Altering a replicate definition when you alter a replicated table
  • Copying external files to grid servers

For example, suppose that you have 100 replication servers and must create a table. You must fragment the table into two new dbspaces. You also must create a new stored procedure to run on the table. With a grid, you would run four commands to perform these tasks on all 100 replication servers, instead of running 400 commands. The command to create the table can also specify that the data in that table is replicated.

You can control the security of the grid by authorizing which users can run grid routines on which servers. You can monitor the results of grid routines and rerun any failed routines on the appropriate servers.

You can configure Connection Managers to route client connection requests to the replication servers of a grid, based on one of the following redirection policies:
  • FAILURE: Connection requests are directed to the replication server that has the fewest apply failures.
  • LATENCY: Connection requests are directed to the replication server that has the lowest transaction latency.
  • ROUNDROBIN: Connection requests are directed in a repeating, ordered fashion (round-robin) to a group of replication servers.
  • WORKLOAD: Connection requests are directed to the replication server that has the lowest workload.