Replication is the process of creating read-only copies (replicas) of a read/write DCE LFS fileset and placing the copies on multiple File Server machines. Replication increases the availability of the fileset in the event of a network or server outage. If one of the machines that houses the fileset becomes unavailable, the fileset can usually still be accessed from another machine. Replication is not available for non-LFS filesets.
Replicate read/write filesets that match the following criteria:
· The files in the fileset are read much more frequently than they are modified.
· The files in the fileset are heavily used (for example, binary files for text editors or other frequently accessed application programs). Replicating the fileset lets you distribute the load for the files it contains across several machines.
· The files in the fileset must remain available. By replicating the fileset on multiple File Server machines, even if one of the machines that houses the fileset becomes unavailable, the fileset is still available from another machine.
· The fileset is mounted at a high level in the cell's file tree (for example, root.dfs and its subdirectories).
The following two types of replication are available for DCE LFS filesets:
· Release Replication, which requires you to issue the fts release command to explicitly update the read-only versions of the read/write source fileset. The command places a read-only copy of the source fileset on the same File Server machine as the source. The Replication Server (repserver process) on each machine that houses a read-only replica then updates the replica on its machine to match the replica stored on the same machine as the read/write fileset. The read-only replicas do not change until you issue the fts release command.
Use Release Replication for a fileset that seldom changes or for a fileset whose replication you need to track closely.
· Scheduled Replication, which requires you to specify replication parameters that control the length of time between automatic updates of the read-only replicas. The Replication Server on each machine that houses a replica updates the replica on its machine according to time intervals that you supply. For a fileset that uses Scheduled Replication, you can use the fts update command to request an immediate update of the fileset's replicas at any time. The command can be used to update all replicas or only the replica at a specific site.
Use Scheduled Replication for a fileset if you prefer to have the system automatically update the fileset's replicas and you do not need to monitor the fileset's replication.
A read/write fileset can be replicated via only one of the two types of replication at any one time. The type of replication to be used for a fileset is set or changed with the fts setrepinfo command. This command is also used to set the replication parameters to be used with the fileset. Some replication parameters are used with both Release and Scheduled Replication to specify how the replicated data is to be used by Cache Managers; other parameters are used only with Scheduled Replication to define how often Replication Servers are to check for updated versions of the source fileset. (An additional site-specific parameter used with Scheduled Replication is set with the fts addsite command; see Replication Type and Parameters for more information about these parameters.)
Whenever you update a read-only replica by either type of replication, DFS ignores any shared byte-range locks held against the replica. Data accessed by a client during an update is not lost or damaged; however, some of the data sent to the client may change as the replica is updated even though the client holds a shared lock.
Each replica of a read/write fileset resides at a specified replication site (a specific File Server machine and aggregate). Before read-only versions of a fileset can be made, the fts addsite command must be used to define the sites where the read-only replicas are to reside. It is not possible to place multiple read-only copies of the same fileset on a single File Server machine, and it is not possible to place a replica of a fileset from one cell on a File Server machine from another cell.
With Release Replication, the fts addsite command must be used to define a replication site on the File Server machine on which the source fileset resides before any subsequent replication sites can be added. The site for the replica can be defined on any aggregate on the source's File Server machine. However, it is best to define the site for this replica on the same aggregate as that on which the source fileset resides, in which case the replica is created as a clone of the source fileset. Because it is created as a clone fileset, which has the same structure as a backup fileset, a replica that exists on the same aggregate as the source requires potentially much less space than a full read-only replica created on a different aggregate. (See Data Sharing Among the Different Types of DCE LFS Filesets for more information about the structure of backup filesets and the sharing of data among the different types of DCE LFS filesets.)
Note: Replication is available in a cell only if the following are true: root.dfs, the cell's main read/write fileset, is a DCE LFS fileset; root.dfs was mounted with an explicit read/write mount point as a subdirectory of itself (the root.dfs fileset) when the cell was configured; and root.dfs is replicated. (See DFS Configuration Issues for information about configuring root.dfs to support replication.)
More:
Replication Information in the FLDB