A successful deployment depends on being mindful during deployment,
operations and ongoing maintenance.
2.6.1. Best Practices: Deployment
Identify the best deployment method for your environment and use that
in production and testing. See
Section 9.1, “Comparing Staging and
Standardize the OS and database prerequisites. There are Puppet and
Chef modules available for immediate use or as a template for
For security purposes you should ensure that you secure the following
areas of your deployment:
Ensure that you create a unique installation and deployment user,
such as tungsten, and set the correct file permissions on
installed directories. See
Section B.2.3, “Directory Locations and Configuration”.
When using ssh and/or SSL, ensure that the ssh key or certificates
are suitably protected. See
Section B.2.2.2, “SSH Configuration”.
Use a firewall, such as iptables to protect the
network ports that you need to use. The best solution is to ensure
that only known hosts can connect to the required ports for
Tungsten Clustering. For more information on the network ports required
for Tungsten Clustering operation, see
Section B.2.2.1, “Network Ports”.
If possible, use authentication and SSL connectivity between hosts
to protext your data and authorisation for the tools used in your
See Section 2.9, “Deployment Security” for more information.
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.
If there are an even number of database servers in the cluster,
configure the cluster with a witness host. An active witness is
preferred but a passive one will ensure stability. See
Section 2.1.4, “Witness Hosts” for an explanation of
the differences and how to configure them.
If you are using
replication, any triggers that run additional
operations must be updated so they do not run on the slave servers.
Make sure you know the structure of the Tungsten Clustering home directory
and how to initialize your environment for administration. See
Section 5.1, “The Tungsten Clustering Home Directory” and
Section 5.2, “Establishing the Shell Environment”.
Prior to migrating applications to Tungsten Clustering test failover and
recovery procedures from Chapter 5, Operations Guide. Be sure to try
recovering a failed master and reprovisioning failed slaves.
2.6.2. Best Practices: Operations
2.6.3. Best Practices: Maintenance
Your license allows for a testing cluster. Deploy a cluster that
matches your production cluster and test all operations and
maintenance operations there.
Schedule regular tests for local and DR failover. This should at least
include switching the master server to another host in the local
cluster. If possible, the DR cluster should be tested once per
Disable any automatic operating system patching processes. The use of
automatic patching will cause issues when all database servers
automatically restart without coordination. See
Section 5.14.3, “Performing Maintenance on an Entire Dataservice”.
Regularly check for maintenance releases and upgrade your environment.
Every version includes stability and usability fixes to ease the