OSF DCE Administration Guide--Core Components

Overview of DCE Security
available for login validation and for read operations even when changes are in the
process of being propagated.
27.6.1 Master and Slave Replicas
Only one replica in a cell, the master replica, accepts updates to its database from
clients. Other replicas, called slave replicas, accept only reads from clients. The master
replica propagates any updates to the slave replicas. For example, either a master or a
slave replica can provide account information to a client program such as /bin/login.
However, if you are adding an account or changing password information, those updates
can be handled only by the master replica.
The process of updating the database differs slightly between the master replica and
slave replicas. Figures 27-3 and 27-4 illustrate the master and slave update processes.
The processes are described in the sections that follow the figures.
Figure 27-3. The Master Replica Update Process
Registry
Database
Disk Memory
Log File
Replica List
Master
Security
Server
Propagation
Queue
Update1,
1/17/89, 8:45
Update 2,
1/17/89, 9:30
.
.
.
Replica List
machineA update 1
machine B update 1
.
.
.
Update 1
Update 2
.
.
.
Registry
Database
The server applies the
update to the database
in virtual memory and
to its propagation
queue. Periodically, the
server writes the data-
base in virtual memory
to disk.
The server stores a copy of
each update in the log file.
This file is used in the event of
a server restart to apply all out-
standing updates to the disk
copy of the database and to re–
create the progagation queue.
Database Update
The master replica uses its
propagation queue to propa-
gate updates to slave replicas.
When the master replica re-
starts, it restores the progaga-
tion queue from the log file.
For each replica in the cell,
the replica list contains the
replica’s network address
and ID, cell–relative name,
and the sequence number
of the replica’s last update.
Log File
124243 Tandem Computers Incorporated 27−5