Important Points to Note before Performing Rolling Upgrades
Your cluster must have MarkLogic 8.0-6 or later installed to perform a rolling upgrade.
The cluster needs to be configured for High Availability (HA). This includes configuring replica forests for your security, schema, and other auxiliary forests.
Do not change your application to take advantage of any 10.0-x features until all the nodes in your cluster have been upgraded to 10.0-x.
You may have to change or modify some of your application code prior to starting the rolling upgrade, so that code will work in a mixed environment.
The primary security, schema, and auxiliary forests must be on the same host, and that host should be the first host you upgrade when upgrading a cluster.
In a mixed node cluster, before the upgrade has been committed, the node that has been upgraded to MarkLogic 10.0-x will be read-only. This is to prevent any configuration changes from the 10.0-x node. We strongly recommend that you not make any configuration changes until you have finished upgrading the entire cluster.
The window of time when a cluster has nodes of varying versions should be small. During this time, do not make application code changes and/or configuration changes. Configuration changes involve the following:
Changes to index, forest, database, application server, host, group, and cluster settings
Changes to security settings such adding/changing/deleting roles, users, privileges, credentials, certificates, etc.
Adding/removing/updating TDE templates
Adding/removing/updating redaction rules
Do not perform any manual merges and disable reindexing while the cluster has nodes that are at different software version levels. Changing error log settings and adding trace events to debug issues should be fine.
After committing a rolling upgrade, you can only restore to the later version (for example, 10.0-1), not to the earlier version (for example, 9.0-6). Running your cluster in an uncommitted state is equivalent to running in the previous (earlier) version of MarkLogic. No 10.0-1 features are available until the upgrade has been committed.
An upgrade of the security database is required after you have committed the new version of MarkLogic.
Please note that, when doing a rolling upgrade from 8.0 to 10.0 (with 9.0 being skipped), you must not use the Management REST API at all. You may use the Admin API, but only to read cluster configuration. This does not affect rolling upgrades from 8.0 to 9.0 or upgrades from 9.0 to 10.0.
Upgrade your cluster to Red Hat Enterprise Linux 7 (x64) before starting the MarkLogic upgrade. Both MarkLogic 9 and MarkLogic 10 will not work on Red Hat Enterprise Linux 6.
It is important to upgrade the disaster recovery cluster first, since the newer version of the software will be able to receive fragments and journal frames encoded on the master cluster.
Before stopping the MarkLogic process on a node, configure your load balancer to divert transactions away from the node being upgraded, and allow all existing and queued transactions to complete.
Mounting a forest takes time. Prioritize the failover of forests for your security, schema, and other auxiliary databases.
Before stopping the MarkLogic process on a node, make sure that all acting replica forests on the other nodes have caught up in replicating content.