1.7 Design, Replication, and Mixed Releases: Avoiding Design Ping-Pong  |
Do you have multiple Domino servers in your environment? Do you upgrade your Domino servers over multiple days, weeks or months? If so, you should be aware of the options available to prevent a problem where the design task and replication are changing the design of your databases daily. This article explains to you how to avoid design ping-pong scenario. |
ShowTable of Contents
Table of Contents
Do you have multiple Domino servers in your environment? Do you upgrade your Domino servers over multiple days, weeks or months? If so, you should be aware of the options available to prevent a problem where the design task and replication are changing the design of your databases daily. This article explains to you how to avoid design ping-pong scenario.
Description of the Problem
There are several ways you may notice that your servers are doing "design ping-pong". You notice in your log that each night when the design task runs, all of your databases are updated. Your users noticed that one day, their mail database was upgraded and the following day their mail file is not upgraded any more. You noticed the replica task is replicating more data than normal.
What can cause this behavior? It is the combination of replication and the design task. By default, the design task runs at 1 a.m. on your server. By default, the line ServerTasksAt1=catalog, design is in the NOTES.INI of every server. When the design task runs, it compares the date and time of the design elements in the template with the design elements in the database. If there is a mismatch, then the design task replaces the existing design element with the one from the template. This is important so that when you upgrade your Domino server, your databases get the latest updates and fixes. Now imagine you have a Domino server you just upgraded to 8.5.2 that replicates with an 8.5.1 server. The following sequence of events may occur:
Day 1: Domino 8.5.2 server upgrades the design of all mail files and system application databases with the latest 8.5.2 updates. During the next replication event between the servers, the 8.5.2 design replicates to any replica databases present on the 8.5.1 server.
Day 2: The Domino 8.5.1 server updates the design of all databases with the copy of design elements it has stored in the copy of its templates. During the next replication event between the servers, the 8.5.1 replicates design to any replica databases present on the 8.5.2 server.
Day 3: The cycle begins again; the Domino 8.5.2 server upgrades the design...
Preventing the Problem
There are a number of ways you can prevent design ping-pong from occurring:
- Replicating templates between servers
- Limiting the design task
- Removing templates from some servers
- Selective replication
Replicating Templates Between Servers
Most templates have the same replica ID between releases. If you allow templates to replicate in your environment, then the latest design will get replicated to any templates that are in common between the servers. For more information, refer to the “Domino Template Replication and Design” Domino wiki article. In this scenario, since all servers have the same design elements when the design task runs, it will recognize that the database has already been updated and thus not update the database again.
Limiting the Design Task
By default, all Domino servers run the design task at 1 a.m. If you need to run in a mixed release environment for a period of time and do not replicate templates, you can choose to modify your server configuration and not run the design task on one or more servers in your domain. The design task is started at 1 a.m. due to the ServerTasksAt1=catalog, design entry in the server NOTES.INI file. You can remove the design task by entering the following command at the Domino console: set config ServerTasksAt1=catalog. Once you have upgraded all of your servers you can easily re-enable the design task using the “set config” command again: set config ServerTasksAt1=catalog,design.
Removing Templates from Some Servers
The design task cannot update the design of databases if the template does not exist on the server. In the scenario described above, the administrator can remove the templates from the 8.5.1 server. Later, as part of the server upgrade, the templates are copied back to the Domino server data directory. Be aware that removing the templates can cause a performance problem on the server if you have clients or servers configured to replicate these files. For details on the potential performance impact of removing the templates, review technotes 1299812 and 1426125.
Selective Replication
When replicating Domino databases and applications, you control which data can replicate. For example, if you only replicate a small subset of databases, you may want to temporarily disable replication of design elements. You can do this in the replication settings of a database as shown in figure 1.
Working with Mixed Clusters
The approaches discussed in this article work great for replica servers, but they may not work for clustered servers. That is because the cluster replicator always replicates design elements. The easiest way to prevent the design from going to the old server is to not run the design task on either server in the cluster. However; without the new design, you cannot use the new features. Also system databases such as names.nsf and admin4.nsf are backwards compatible so the new design will work fine on your older servers. Because of the complexities here, it is best to upgrade your clustered servers together or within a short period of time. |
|
|
|
|
|
| Version 2 |
April 21, 2011 |
10:46:52 AM |
by Amy Hoerle  |
|
|