Reverting from version 7.0 or later to a pre-7.0 version can be done using the
revert-update command with some extra steps. This is also the case
when updating or reverting from a pre-22.214.171.124 to 126.96.36.199 or later. These steps are
listed when the
revert-update tool are run
as well. You may need to perform one or more of the following tasks, depending on your
installation and configuration:
- When updating or reverting from 188.8.131.52 or later to a pre-184.108.40.206 version, indexes
may need to be rebuilt. Older versions of the server use an incompatible format for
Local DB Composite Indexes. To update a server with composite indexes in the
previous format, delete these indexes and re-run the update. After the update is
complete, recreate the indexes and use the
rebuild-indextool to rebuild the indexes. The command for recreating an index will be in the "Undo" portion of the
logs/config-audit.logfile. If you wish to later revert to an older version, delete and recreate those composite indexes again after the revert has completed.
- When updating to 7.x for the first time, instance names will need to be set for each
server in the topology if they were not previously set. This is done with the
$ bin/dsconfig --bindDN "cn=Directory Manager" \ --bindPassword secret \ --no-prompt set-global-configuration-prop \ --set instance-name:<name>
- Topology information such as server instances, instance and secret keys, server
groups, and administrator users have moved to the topology portion of the
configuration from the
adminbackend. As long as new servers are not added to the topology after this update, the
revert-updatecommand can be used to return to the previous version.
However, if new servers are added, then the restored
adminbackend of this server will not contain information about the new servers, and the local server will not be able to communicate with any other servers in the topology. New servers should not be added to the topology if reverting this update is a possibility.
- If new servers were added to the topology after the update, the new servers must be temporarily removed from the topology until all servers have been reverted to the previous version.
- When a server is reverted to a pre-7.x version, any servers in the topology using
the topology portion of the configuration (rather than the
adminbackend) will needto know that the reverted server was downgraded to the
adminbackend. This is done by running the following
dsconfigcommand on one of the servers that has not been reverted:
$ bin/dsconfig set-server-instance-prop \ --instance-name <Reverted server instance name> \ --set server-version:<Version to which server is reverted>
- If the topology does not have a master server when this command is run, it will not
succeed. In this case, one of the remaining updated servers in the topology must be
made master with the following command. This will enable the chosen instance to run
the first command
$ bin/dsconfig set-global-configuration-prop \ --set force-as-master-for-mirrored-data:true
- The 7.x server version includes database changes that are not compatible with
previous server versions (6.x or older). If you wish to later revert to an older
version, the data must be exported to LDIF before performing the reversion.
Re-import the data after the revert process has completed. In addition, the
db/changelog/directories in the reverted server root must be deleted after the revert has completed.
When starting up the server for the first time after a revert has been run, and the necessary extra steps have been completed, the server will display warnings about "offline configuration changes," but they are not critical and will not appear on subsequent startups.