Chapter 3. Deployment: MySQL Topologies

Table of Contents

3.1. Deploying Standalone HA Clusters
3.1.1. Prepare: Standalone HA Cluster
3.1.2. Install: Standalone HA Cluster
3.1.3. Best Practices: Standalone HA Cluster
3.2. Deploying Composite Active/Passive Clustering
3.2.1. Prepare: Composite Active/Passive Cluster
3.2.2. Install: Composite Active/Passive Cluster
3.2.3. Best Practices: Composite Active/Passive Cluster
3.2.4. Adding a remote Composite Cluster
3.3. Deploying Multi-Site/Active-Active Clustering
3.3.1. Prepare: Multi-Site/Active-Active Clusters
3.3.2. Install: Multi-Site/Active-Active Clusters
3.3.3. Best Practices: Multi-Site/Active-Active Clusters
3.3.4. Configuring Startup on Boot
3.3.5. Resetting a single dataservice
3.3.6. Resetting all dataservices
3.3.7. Provisioning during live operations
3.3.8. Adding a new Cluster/Dataservice
3.3.9. Enabling SSL for Replicators Only
3.3.10. Dataserver maintenance
3.4. Deploying Composite Active/Active Clusters
3.4.1. Prepare: Composite Active/Active Clusters
3.4.2. Install: Composite Active/Active Clusters
3.4.3. Best Practices: Composite Active/Active Clusters
3.4.4. Configuring Startup on Boot
3.4.5. Resetting a single dataservice
3.4.6. Resetting all dataservices
3.4.7. Dataserver maintenance
3.4.8. Adding a Cluster to a Composite Active/Active Topology
3.5. Deploying Tungsten Connector Only
3.6. Deploying Additional Datasources, Managers, or Connectors
3.6.1. Adding Datasources to an Existing Deployment
3.6.2. Adding Active Witnesses to an Existing Deployment
3.6.3. Replacing an Active Witness as a Full Cluster Node
3.6.4. Replacing a Full Cluster Node as an Active Witness
3.6.5. Adding Passive Witnesses to an Existing Deployment
3.6.6. Adding Connectors to an Existing Deployment
3.6.7. Converting from a single cluster to a composite cluster
3.7. Replicating Data Into an Existing Dataservice
3.8. Replicating Data Out of a Cluster
3.8.1. Prepare: Replicating Data Out of a Cluster
3.8.2. Deploy: Replicating Data Out of a Cluster
3.9. Replicating from a Cluster to a Datawarehouse
3.9.1. Replicating from a Cluster to a Datawarehouse - Prerequisites
3.9.2. Replicating from a Cluster to a Datawarehouse - Configuring the Cluster Nodes
3.9.3. Replicating from a Cluster to a Datawarehouse - Configuring the Cluster-Extractor
3.10. Migrating and Seeding Data
3.10.1. Migrating from MySQL Native Replication 'In-Place'
3.10.2. Migrating from MySQL Native Replication Using a New Service
3.10.3. Seeding Data through MySQL

Creating a Tungsten Clustering (for MySQL) Dataservice using Tungsten Cluster combines a number of different components, systems, and functionality, to support a running database dataservice that is capable of handling database failures, complex replication topologies, and management of the client/database connection for both load balancing and failover scenarios.

How you choose to deploy depends on your requirements and environment. All deployments operate through the tpm command. tpm operates in two different modes:

  • tpm staging configuration — a tpm configuration is created by defining the command-line arguments that define the deployment type, structure and any additional parameters. tpm then installs all the software on all the required hosts by using ssh to distribute Tungsten Cluster and the configuration, and optionally automatically starts the services on each host. tpm manages the entire deployment, configuration and upgrade procedure.

  • tpm INI configuration — tpm uses an INI to configure the service on the local host. The INI file must be create on each host that will be part of the cluster. tpm only manages the services on the local host; in a multi-host deployment, upgrades, updates, and configuration must be handled separately on each host.

The following sections provide guidance and instructions for creating a number of different deployment scenarios using Tungsten Cluster.