Understanding Deployment Styles and Topologies
The following sections provide understanding around the different styles of deployment available and the different topologies that can be configured using Tungsten Replicator
Replicator Extraction Operation
| Replication Operation | Support |
|---|---|
| Statements Replicated | Yes, within MySQL/MySQL Topologies only |
| Rows Replicated | Yes |
| Schema Replicated | Yes, within MySQL/MySQL Topologies only |
ddlscan Supported | Yes, supported for mixed MySQL, and data warehouse targets |
Tungsten Replicator for MySQL operates by
- Reading the MySQL binary log (binlog) directly from the disk and translating that content and session information into the THL. Using this method to read the binlog in its different formats, such as the statement, row and mixed-based logging.
- Remotely from the MySQL server over a network, including reading from a Cloud-Managed instance such as Amazon Aurora. This enables the replicator to read the information remotely, either on services where direct access to the binlog is not available, or where we cannot be installed. This is also referred to as Offboard installation
The following diagrams show these two methods of extraction
Tungsten Replicator for MySQL is supported within the following environments:
- MySQL Community Edition
- MySQL Enterprise Edition from Oracle
- Percona
- MariaDB
- Amazon Aurora
- Google Cloud MySQL
- Microsoft Azure MySQL
In addition, the following requirements and limitations are in effect:
- Primary Keys : It is strongly advised that all tables have primary keys when the target is MySQL, Oracle or Postgres. For all other targets, this requirement is mandatory.
- Row-based binary logging must be configured for heterogeneous deployment models
- Datatype support varies, depending upon the target. Check applier documentation appropriate to deployment target for more detail.
- DDL is only replicated in MySQL to MySQL deployments