Propagation
Monitoring Propagation
times a day. For example, if a prop_q.wrk file exists with a file creation date older than 24 hours from current time, or if the prop_q file size is unusually large, the propagation cycle may very likely be stalled.
Another example would be if a prop_hostname file that is older than 48 hours or is unusually large, this indicates a propagation problem between the primary and secondary servers as specified in hostname.
principal.ok Time Stamp Does Not Update
You may notice that the time stamp of the principal.ok file on the primary server does not update after propagation. This is the expected behavior. On the primary security server, the principal.ok file retains the date when the database was initially created. This date should not be changed, unless the database is deleted and rebuilt.
On the secondary server, the principal.ok file is updated each time a propagation full dump from the primary is successfully completed. During a full dump, the database updates are copied to temporary files on the secondary server. Once all of the temporary files are updated, they are put into place on the secondary server as permanent database files. If a full dump is not successfully completed, the principal database files on the secondary server, including the principal.ok file, remain unchanged and the date does not change.
Since most propagation occurs as incremental propagation, an old time stamp on a secondary server’s principal.ok file is not necessarily an indication of failed propagation. A new principal.ok file can indicate a failure.
Comparing the Database to its Copies
There is no
It is important to periodically check that the primary and secondary databases are synchronized. An
•Authentication problems occur
•Administration functions normally
•Log files indicate propagation problems
Chapter 7 | 231 |