Navigation

Upgrade Ops Manager

    This tutorial describes how to upgrade an existing Ops Manager installation.

    Upgrade Path

    The version of your existing Ops Manager installation determines the upgrade path you must take to upgrade to Ops Manager 4.2 or later.

    Important

    • You must follow the upgrade path for your existing version to perform necessary database migrations.
    • To protect your data, Ops Manager refuses to start direct upgrades from versions 1.8.x and 2.0.x to version 3.4 or later.
    • In high availability environments, you must shut down every Ops Manager application server before starting any Ops Manager application servers upgraded to the new version.

    The following table lists upgrade paths for all versions:

    Existing Version Upgrade Path
    4.2.x Use this tutorial to upgrade from Ops Manager 4.2.x to a more recent 4.2.x version.
    4.0.x Use this tutorial to upgrade from Ops Manager 4.0.x to version 4.2.x.
    3.6.x Use this tutorial to upgrade from Ops Manager 3.6.x to version 4.0.x.
    3.4.x Refer to the v3.6 upgrade documentation to upgrade from Ops Manager 3.4.x to version 3.6.x.
    2.x or earlier For the specific upgrade path for your version, refer to v3.4 upgrade documentation.

    There are no supported downgrade paths for Ops Manager.

    Important

    It is crucial that you back up the existing conf-mms.properties and gen.key files because the upgrade process deletes them.

    Important

    It is crucial that you back up the existing conf-mms.properties and gen.key files because the upgrade process deletes them.

    Advisories

    Upgrading to Ops Manager 4.2

    Before upgrading Ops Manager from 4.0 to 4.2, complete the following actions:

    Backup

    Backup support for MongoDB 4.2 with "featureCompatibilityVersion" : 4.2 is currently extremely limited. Support will be extended in future releases of Ops Manager.

    If you are running MongoDB 4.2 with "featureCompatibilityVersion" : 4.2, you:

    • Cannot back up sharded clusters. Do not upgrade sharded clusters to "featureCompatibilityVersion" : 4.2 if you need to back up your sharded cluster.
    • Cannot restore to a specific a point in time or use a queryable restores. Do not upgrade to "featureCompatibilityVersion" : 4.2 if you require point in time or queryable restores.
    • Cannot use namespace filter lists to define the namespaces included in a backup.
    • Cannot specify a sync source database.
    • Cannot save your backup to a file system store.
    • Must deploy a MongoDB Agent with every mongod node in the cluster.

    Backup and restore performance decreases for MongoDB 4.2 replica sets with many small collections: those with tens of thousands of collections with less than 1 GB of data per collection.

    MongoDB Agent

    • MongoDB Agent doesn’t support automation of MongoDB 2.6 and 3.0.
    • Customers using Kerberos (GSSAPI) authentication for unmanaged Monitoring and/or Backup Agents must create a single new GSSAPI principal for the combined MongoDB Agent.
    • MongoDB Agent doesn’t support the sslRequireValidServerCertificates parameter. You can no longer use the workaround of manually managed Monitoring and Backup Agents.

    Automation

    The Version Manager has been removed. All versions now can be used and Ops Manager internally determines which versions the MongoDB Agent needs to have available in its configuration. The ability to configure custom builds has been retained.

    Ops Manager

    • When using Ops Manager in IPv6-only environments, any connections to the internet must support dual-stack IPv4/IPv6. Further, IP whitelisting supports IPv4-style addresses only. This will be resolved in a future release in the Ops Manager 4.2 series.
    • The containerization of Ops Manager has been included as an alpha release. This alpha release is unsupported for production use. The Backup Daemon is not containerized.

    Prerequisites

    Hardware and Software Requirements

    Your servers must meet the Ops Manager System Requirements.

    Warning

    Failure to configure servers according to the Ops Manager System Requirements, including the requirement to read the MongoDB Production Notes, can lead to production failure.

    If your backing databases run the MMAPv1 storage engine, the upgrade process fails. Ops Manager prompts you to upgrade the storage engine for those backing databases to WiredTiger.

    Administrator Privileges

    You must have administrator privileges on the servers on which you perform the upgrade.

    Platform Compatibility

    Before you upgrade Ops Manager, make sure:

    If you upgraded the platform for the MongoDB Agent hosts, upgrade the MongoDB Agents before upgrading Ops Manager.

    Procedure

    If you have an Ops Manager 4.2 installation with more than one Ops Manager host pointing to the same Application Database, you can upgrade Ops Manager to a newer 4.2 version without incurring monitoring downtime. During this upgrade, Ops Manager enters a state known as Upgrade Mode: a state in which Ops Manager is available during an upgrade. The benefits of this mode are that throughout the upgrade process:

    • Alerts and monitoring operate
    • Ops Manager instances remain live
    • Ops Manager Application may be accessed in read-only mode
    • Ops Manager APIs that write or delete data are disabled

    Your Ops Manager instance stays in Upgrade Mode until all Ops Manager hosts have been upgraded and restarted.

    Note

    • Upgrade Mode works with Ops Manager 4.2 and later only.
    • You need to stop all Backup Daemons before upgrading to later versions of 4.2.x.

    Important

    Before you perform the upgrade procedure, ensure that you have a current backup of the Ops Manager backing databases. To perform a full backup, see Shut Down and Back Up Ops Manager.

    Use this procedure to upgrade the Ops Manager Application on hosts running Microsoft Windows:

    1

    Shut down Ops Manager.

    To shutdown Ops Manager:

    1. Click the Start button.
    2. Click Administrative Tools.
    3. Click Services.
    4. Right-click the MongoDB Ops Manager HTTP Service and select Stop.
    5. Right-click the MongoDB Ops Manager Backup Daemon Service and select Stop.
    2

    Uninstall the current version of Ops Manager.

    To uninstall Ops Manager:

    1. Click the Start button.
    2. Click Control Panel.
    3. Click Programs and Features.
    4. Right-click MongoDB Ops Manager and select Uninstall.

    Important

    If you do not uninstall the previous version of Ops Manager, you receive an error message during the upgrade.

    3

    Download the latest version of the Ops Manager package.

    1. Open your preferred browser to visit the MongoDB Download Center on MongoDB.com.

      If you start on MongoDB.com instead of following the link above, click Get MongoDB, then select Ops Manager from the Tools menu.

    2. From the Platforms drop-down menu, click Microsoft Windows Server 2008 R2, 2012, 2012 R2 + 2016.

    3. From the Packages drop-down menu, click MSI.

    4. Click Download.

    Note

    The downloaded package is named mongodb-mms-<version>.msi, where <version> is the version number.

    4

    Install the Ops Manager MSI package on each server being used for Ops Manager.

    Note

    If you have multiple Ops Manager hosts using a single Application Database, you are running your Ops Manager deployment with high availability. After you upgrade one Ops Manager host of a highly available Ops Manager deployment, that deployment enters Upgrade Mode. You should not upgrade more than one Ops Manager host at a time.

    To install:

    1. Double click the MSI package.
    2. Follow the instructions in the Setup Wizard.
    3. During setup, the Configuration/Log Folder step prompts you to specify a folder where the configuration and log files will be stored.

    The installation restricts access to the folder to users with the Administrator access privileges only.

    5

    Start Ops Manager on every server.

    To start the service:

    1. Click the Start button.
    2. Click Administrative Tools.
    3. Click Services.
    4. In the Services list, right-click the MongoDB Ops Manager HTTP Service and select Start.
    6

    Restart all Ops Manager services.

    7

    Update all Agents.

    Once your upgrade has finished, login to your Ops Manager instance. Ops Manager displays a banner that says One or more agents are out of date.

    Click Update All Agents, then confirm the changes.

    Use this procedure to upgrade Linux systems that do not use deb or rpm packages.

    1

    Stop all existing Ops Manager services.

    <install_dir>/bin/mongodb-mms stop
    
    2

    On each Ops Manager server, back up your existing configuration files and logs to a directory other than the install directory.

    Important

    You need the backed-up <install_dir>/conf/conf-mms.properties file for later in this procedure.

    Example

    The following commands back up the configuration files and logs to your home directory:

    cp -a <install_dir>/conf ~/mms_conf.backup
    cp -a <install_dir>/logs ~/mms_logs.backup
    
    3

    Download the latest version of the Ops Manager archive.

    1. Open your preferred browser to visit the MongoDB Download Center on MongoDB.com.

      If you start on MongoDB.com instead of following the link above, click Get MongoDB, then select Ops Manager from the Tools menu.

    2. From the Platforms drop-down menu, click one of the following options:

      • Red Hat + CentOS 6, 7 / SUSE 12 / Amazon Linux
      • Red Hat 7 (ppc64le)
      • Ubuntu 14.04, 16.04 + 18.04
      • Ubuntu 16.04 (ppc64le)
    3. From the Packages drop-down menu, click TAR.GZ for x86_64 architecture or TAR.GZ (PPC64LE) for ppc64le architecture.

    4. Click Download.

    Note

    The downloaded package is named mongodb-mms-<version>.x86_64.tar.gz, where <version> is the version number.

    4

    Install the Ops Manager package on each server being used for Ops Manager.

    Note

    If you have multiple Ops Manager hosts using a single Application Database, you are running your Ops Manager deployment with high availability. After you upgrade one Ops Manager host of a highly available Ops Manager deployment, that deployment enters Upgrade Mode. You should not upgrade more than one Ops Manager host at a time.

    Navigate to the directory into which you want to install Ops Manager. Extract the archive to that directory:

    tar -zxf mongodb-mms-<version>.x86_64.tar.gz
    
    5

    On each Ops Manager server, restore the backed up logs and configuration files into the Ops Manager installation directory.

    All log files should be restored. Most, but not all, configuration file should be restored. Restore:

    conf-mms.properties
    The settings for this Ops Manager deployment.
    gen.key
    The encryption key for the backing databases of this Ops Manager deployment.

    Example

    These commands restore the configuration files and logs from your home directory:

    cp -a ~/mms_logs.backup <install_dir>/logs
    cp -a ~/mms_conf.backup/conf-mms.properties <install_dir>/conf/conf-mms.properties
    cp -a ~/mms_conf.backup/gen.key <install_dir>/conf/gen.key
    
    6

    Optional. On each Ops Manager server, merge any needed changes into the mms.conf file from your backup.

    The mms.conf file is rarely customized, as it contains port and JVM configuration settings. If you modified the ports or the JVM settings that Ops Manager uses, you need to re-apply those changes from your backup copy to the mms.conf file after Ops Manager is upgraded.

    The upgrade to Ops Manager 4.1 and 4.2 removed the -d64 flag from the JAVA_MMS_UI_OPTS parameter.

    7

    Start Ops Manager on every server.

    Issue the following command:

    <install_dir>/bin/mongodb-mms start
    
    8

    Update all Agents.

    Once your upgrade has finished, login to your Ops Manager instance. Ops Manager displays a banner that says One or more agents are out of date.

    Click Update All Agents, then confirm the changes.

    Use this procedure to upgrade the Ops Manager Application on hosts installed using deb packages:

    1

    Stop all existing Ops Manager services.

    sudo service mongodb-mms stop
    
    2

    Download the latest version of the Ops Manager package.

    1. Open your preferred browser to visit the MongoDB Download Center on MongoDB.com.

      If you start on MongoDB.com instead of following the link above, click Get MongoDB, then select Ops Manager from the Tools menu.

    2. From the Platforms drop-down menu, click one of the following options:

      • Ubuntu 16.04 + 18.04
      • Ubuntu 16.04 (ppc64le)
    3. From the Packages drop-down menu, click DEB for x86_64 architecture or DEB (PPC64LE) for ppc64le architecture (Ubuntu 16.04 only).

    4. Click Download.

    Note

    The downloaded package is named mongodb-mms-<version>.x86_64.deb, where <version> is the version number.

    3

    Install the Ops Manager package on each server being used for Ops Manager.

    Note

    If you have multiple Ops Manager hosts using a single Application Database, you are running your Ops Manager deployment with high availability. After you upgrade one Ops Manager host of a highly available Ops Manager deployment, that deployment enters Upgrade Mode. You should not upgrade more than one Ops Manager host at a time.

    1. Install the .deb package on each Ops Manager Application and Backup Daemon host. Issue the following command, where <version> is the version of the .deb package:

      sudo dpkg -i mongodb-mms_<version>_x86_64.deb
      
    2. When prompted whether to overwrite the currently installed version of mms.conf, you should type Y to replace the existing file.

    3. If you modified the ports or the JVM settings that Ops Manager uses, you need to re-apply those changes to the mms.conf file after Ops Manager is upgraded.

      The upgrade to Ops Manager 4.1 and 4.2 removed the -d64 flag from the JAVA_MMS_UI_OPTS parameter.

    4

    Start Ops Manager on every host.

    sudo service mongodb-mms start
    
    5

    Restart all Ops Manager services.

    6

    Update all Agents.

    Once your upgrade has finished, login to your Ops Manager instance. Ops Manager displays a banner that says One or more agents are out of date.

    Click Update All Agents, then confirm the changes.

    Use this procedure to upgrade the Ops Manager Application on hosts installed using rpm packages:

    1

    Stop all existing Ops Manager services.

    On RHEL, CentOS, SUSE12 hosts that use systemd, issue the following command:

    sudo service mongodb-mms stop
    

    For Amazon Linux 1 platforms that use SysVInit, issue the following command:

    sudo /etc/init.d/mongodb-mms stop
    
    2

    Download the latest version of the Ops Manager package.

    1. Open your preferred browser to visit the MongoDB Download Center on MongoDB.com.

      If you start on MongoDB.com instead of following the link above, click Get MongoDB, then select Ops Manager from the Tools menu.

    2. From the Platforms drop-down menu, click one of the following options:

      • Red Hat + CentOS 6, 7 / SUSE 12 / Amazon Linux
      • Red Hat 7 (ppc64le)
    3. From the Packages drop-down menu, click RPM for x86_64 architecture or RPM (PPC64LE) for ppc64le architecture (RHEL 7 only).

    4. Click Download.

    Note

    The downloaded package is named mongodb-mms-<version>.x86_64.rpm, where <version> is the version number.

    3

    Install the Ops Manager package on each Ops Manager host.

    Note

    If you have multiple Ops Manager hosts using a single Application Database, you are running your Ops Manager deployment with high availability. After you upgrade one Ops Manager host of a highly available Ops Manager deployment, that deployment enters Upgrade Mode. You should not upgrade more than one Ops Manager host at a time.

    To install the .rpm package on each Ops Manager Application host, issue the following command, where <version> is the version of the .rpm package:

    sudo rpm -Uvh mongodb-mms-<version>.x86_64.rpm
    

    RPM Upgrade to 4.1+ modifies Ops Manager mms.conf file

    If you modified the ports or the JVM settings that Ops Manager uses, you need to re-apply those changes to the mms.conf file after Ops Manager is upgraded.

    The upgrade to Ops Manager 4.1 and 4.2 removed the -d64 flag from the JAVA_MMS_UI_OPTS parameter.

    4

    Start Ops Manager on every host.

    On RHEL, CentOS, SUSE12 hosts that use systemd, issue the following command:

    sudo service mongodb-mms start
    

    For Amazon Linux 1 platforms that use SysVInit, issue the following command:

    sudo /etc/init.d/mongodb-mms start
    
    5

    Update all Agents.

    Once your upgrade has finished, login to your Ops Manager instance. Ops Manager displays a banner that says One or more agents are out of date.

    Click Update All Agents, then confirm the changes.