2.2. Best Practices

A successful deployment depends on being mindful during deployment, operations and ongoing maintenance.

2.2.1. Best Practices: Deployment

  • Standardize the OS and database prerequisites. There are Ansible modules available for immediate use within AWS, or as a template for modifications. The product is also available to subscribe to via the AWS and GCP Marketplaces for customers without an existing annual subscription license.

    More information on the Ansible method is available in this blog article.

  • Ensure that the output of the `hostname` command and the nodename entries in the Tungsten configuration match exactly prior to installing Tungsten.

    The configuration keys that define nodenames are: slaves, dataservice-slaves, members, master, dataservice-master-host, masters and relay

  • For security purposes you should ensure that you secure the following areas of your deployment:

  • Choose your topology from the deployment section and verify the configuration matches the basic settings. Additional settings may be included for custom features but the basics are needed to ensure proper operation. If your configuration is not listed or does not match our documented settings; we cannot guarantee correct operation.

  • It is strongly advised to include install=true to your configuration to ensure all components are correctly registered with your OS systemctl (or equivalent) processes, ensuring automatic restart should a host reboot.

    Alternatively, you should run deployall following installation.

  • If you are using ROW replication, any triggers that run additional INSERT/UPDATE/DELETE operations must be updated so they do not run on the Replica servers.

  • Make sure you know the structure of the Tungsten Cluster home directory and how to initialize your environment for administration. See Section 7.1, “The Home Directory” and Section 7.2, “Establishing the Shell Environment”.

  • Prior to migrating applications to Tungsten Cluster test failover and recovery procedures from Chapter 7, Operations Guide. Be sure to try recovering a failed Primary and reprovisioning failed Replicas.

2.2.2. Best Practices: Upgrade

In this section we identify the best practices for performing a Tungsten Software upgrade.

  • See Section 9.2.3, “Upgrades with an INI File” for more detailed information.

  • Here is the sequence of events for a proper Tungsten upgrade on a simple Primary-Replica replication topology:

    • Login to the Customer Downloads Portal and get the latest version of the software.

    • Copy the file (i.e. tungsten-replicator-6.1.25-6.tar.gz) to each host that runs a Tungsten component.

    • On every host:

      • Extract the tarball under /opt/continuent/software/

      • cd to the newly extracted directory

      • Run the Tungsten Package Manager tool

    • For example, here are the steps in order, that should be executed on every host:

      shell> cd /opt/continuent/software
      shell> tar xvzf tungsten-replicator-6.1.25-6.tar.gz
      shell> cd tungsten-replicator-6.1.25-6
      shell> tools/tpm update --replace-release

2.2.3. Best Practices: Operations

2.2.4. Best Practices: Maintenance

  • Deploy an installation that matches your production enviornment and test all operations and maintenance operations there.

  • Disable any automatic operating system patching processes. The use of automatic patching will cause issues when all database servers automatically restart without coordination.

  • Regularly check for maintenance releases and upgrade your environment. Every version includes stability and usability fixes to ease the administrative process.