1.1

By default, all servers that host data are added to the "default" server group.
Different logical database schema are often managed in different server groups. For example, an order management
system might manage all customers and their orders in an "Orders" schema deployed to one server group. The
same system might manage shipping and logistics data in a different server group. A single peer or server can
participate in multiple server groups, typically as a way to colocate related data or to control the number of
redundant copies in replicated tables.
With support for dynamic group membership, the number of processes hosting data for a server group can change
dynamically. However, this dynamic aspect of server group membership is abstracted away from the application
developer, who can look at a server group as a single logical server.
Server groups only determine those peers and servers where a table's data is being managed. Tables are always
accessible for any peer member of the distributed system, and from thin clients that connect to a single server.
When you invoke server side procedures, you can parallelize the execution of the procedure on all members in
the server group. These data-aware procedures also execute on any peer clients that belong to the server groups.
Without associating tables to specific member IP addresses, the capacity of a server group can be dynamically
increased or decreased without any impact to existing servers or client applications. SQLFire can automatically
rebalance the tables in the server group to the newly added members.
Adding Members to Server Groups
You define server group membership and/or create a server group when you start a SQLFire member using the
server-groups boot property.
57
Using Server Groups to Manage Data