In a distributed database environment, databases are installed and operated on different servers. This makes it a challenge to offer information to users through HTTP service. This database server offers a solution to such an environment. When installed on multiple machines, all the servers communicate with others to form a cluster of database servers. A server registers it when it is started, and unregisters when it is stopped. The group is formed dynamically at run-time. Every server in the DSG knows what other servers can offer and will be able to process database requests even though the database is on another server. The physical location of a database is transparent to users. An SQL statement sent to machine A may be actually processed by machine B.

Here are some of the advantages of DSG:

 Database access and location transparency: Database can be accessed independent of the server location. The Database server could be in a LAN, WAN or on the Internet. But database service is available on the DSG member.

 Scalability: Database service can be added/removed easily without disturbing existing database service. A new database server can join DSG at any time and leave the DSG when needed (i.e., shutdown for maintenance).

 Security: When configured properly, database serviced can be pushed back from WEB servers. Devices, such as routers, can be added between the WEB server and database server to filter out unsafe packages. It is always a good idea to separate WEB services and Database services.

A DSG is uniquely identified by its address and port. Members in the DSG multicast messages using the same address and port through User Datagram Protocol (UDP). All members in the same group must have the same address and port. The address is an IP class D address in the range of 224.0.1.0 to 239.255.255.255. Port can be any valid IP port unique to your network.

You may have multiple DSGs by using either different ports or addresses. Address and port can be specified in the server configuration file Similar to the following:

A server can join a DSG by specify a membership type in the server configuration file. Membership is an integer that represents how the server participates in the DSG communication.

Where n can be

 0: The server is not a member of any DSG group, and will not accept or multicast messages.

 1: The server joins the DSG as a multicast only server. It doesn't receive DSG messages. This type of server is sometime referred to as export server. It publishes its own database resources, but doesn't care what others are offering.

 2. The server joins the DSG as a receive-only server. It doesn't multicast messages. This type of server is also referred to as import server. It makes available database resources located on other servers, but doesn't publish its own database resources.

3. The server multicasts and receives DSG messages. This is a full membership server.

By assigning different DSG membership to your servers, you can create totally different architectures of database services. From DSG ring (in which all members are full membership servers) to DSG hierarchy (in which only one server is a full membership server that serves as the interface to users, the rest of servers are export-only servers).