Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: Architecture for replicating a database through log shipping. A replication service replicates data using one or more new internal application program interfaces (APIs), a replay configuration API which abstracts configuration information for each destination (or target) instance. APIs for log file management as part of the replication process are provided for opening communications for log shipping, tracking success of log shipping and closing out log shipping communications. Log shipping APIs are also provided for log truncation control. A ship control object is provided as a base class which includes an API for other components of the replication service to operate on log files when the log files are placed into a log directory. The ship control API is utilized by the replication service and for interaction with storage system log files.

Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: Architecture for replicating a database through log shipping. A replication service replicates data using one or more new internal application program interfaces (APIs), a replay configuration API which abstracts configuration information for each destination (or target) instance. APIs for log file management as part of the replication process are provided for opening communications for log shipping, tracking success of log shipping and closing out log shipping communications. Log shipping APIs are also provided for log truncation control. A ship control object is provided as a base class which includes an API for other components of the replication service to operate on log files when the log files are placed into a log directory. The ship control API is utilized by the replication service and for interaction with storage system log files.

Abstract: Architecture for replicating a database through log shipping. A replication service replicates data using one or more new internal application program interfaces (APIs), a replay configuration API which abstracts configuration information for each destination (or target) instance. APIs for log file management as part of the replication process are provided for opening communications for log shipping, tracking success of log shipping and closing out log shipping communications. Log shipping APIs are also provided for log truncation control. A ship control object is provided as a base class which includes an API for other components of the replication service to operate on log files when the log files are placed into a log directory. The ship control API is utilized by the replication service and for interaction with storage system log files.

Abstract: A central controlling service for datacenter activation/deactivation control in a cluster deployment to assist in preventing a split-brain scenario. The central controlling service provides a central point of control in the datacenter for application servers to periodically query as to whether to go offline, online, or normal. Redundancy of the central service facilitates detection of datacenter failure by the redundant services interacting to resolve the state of control information. This control information is then used to answer the server queries. On startup from a datacenter failure, a single instance of the central service queries other redundant instance(s) to determine if the single instance is starting up from a datacenter-wide failure or from operations other than total datacenter failure. If the failure is datacenter-wide, a central service protocol assists in resolving to the single service keeping the associated datacenter servers offline; otherwise, the server queries are answered to go online.

Abstract: Architecture that reduces data loss resulting from failover in an asynchronous log shipping deployment, but leveraging mid-tier and frontend servers to fill in lost data. In an asynchronous log shipping operation, a replication component asynchronously replicates messaging data to a backend server in accordance with one or more replication operations, which can be updates to databases on the backend server. These databases can include messaging data, such as email address books, mailboxes, etc. A history component maintains a history of replication operations on a frontend server. In the event of a lossy failover, a replay component is used for replaying the replication operations from the history to the backend server.

Abstract: The present invention provides for a messaging system that automatically identifies a forest that corresponds to a particular recipient of a message, without using a common or unified directory that maps forests with recipients. In a network with multiple forests, each forest having multiple recipients, when a message is received at a message server with a destination address that does not uniquely identify a particular forest, the present invention provides for using a standard messaging protocol for querying each forest. The forests respond with status codes that indicate whether or not a recipient associated with the destination address corresponds to the forest being queried. If a status code indicates that the recipient corresponds to the particular forest, information may be stored and used to quarry that particular forest first, before querying other forests within the network.

Abstract: Architecture that reduces data loss resulting from failover in an asynchronous log shipping deployment, but leveraging mid-tier and frontend servers to fill in lost data. In an asynchronous log shipping operation, a replication component asynchronously replicates messaging data to a backend server in accordance with one or more replication operations, which can be updates to databases on the backend server. These databases can include messaging data, such as email address books, mailboxes, etc. A history component maintains a history of replication operations on a frontend server. In the event of a lossy failover, a replay component is used for replaying the replication operations from the history to the backend server.

Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: A central controlling service for datacenter activation/deactivation control in a cluster deployment to assist in preventing a split-brain scenario. The central controlling service provides a central point of control in the datacenter for application servers to periodically query as to whether to go offline, online, or normal. Redundancy of the central service facilitates detection of datacenter failure by the redundant services interacting to resolve the state of control information. This control information is then used to answer the server queries. On startup from a datacenter failure, a single instance of the central service queries other redundant instance(s) to determine if the single instance is starting up from a datacenter-wide failure or from operations other than total datacenter failure. If the failure is datacenter-wide, a central service protocol assists in resolving to the single service keeping the associated datacenter servers offline; otherwise, the server queries are answered to go online.

Abstract: Architecture for replicating a database through log shipping. A replication service replicates data using one or more new internal application program interfaces (APIs), a replay configuration API which abstracts configuration information for each destination (or target) instance. APIs for log file management as part of the replication process are provided for opening communications for log shipping, tracking success of log shipping and closing out log shipping communications. Log shipping APIs are also provided for log truncation control. A ship control object is provided as a base class which includes an API for other components of the replication service to operate on log files when the log files are placed into a log directory. The ship control API is utilized by the replication service and for interaction with storage system log files.