The fan-in topology is the logical opposite of a master/slave topology. In a fan-in topology, the data from two masters is combined together on one slave. Fan-in topologies are often in situations where you have satellite databases, maybe for sales or retail operations, and need to combine that information together in a single database for processing.
Within the fan-in topology:
host1 is the master replicating to host3
host2 is the master replicating to host3
Some additional considerations need to be made when using fan-in topologies:
If the same tables from each each machine are being merged together, it is possible to get collisions in the data where auto increment is used. The effects can be minimized by using increment offsets within the MySQL configuration:
auto-increment-offset = 1 auto-increment-increment = 4
Fan-in can work more effectively, and be less prone to problems with the
corresponding data by configuring specific tables at different sites.
For example, with two sites in New York and San Jose databases and
tables can be prefixed with the site name, i.e.
Alternatively, a filter can be configured to rename the database
sales dynamically to the
corresponding location based tables. See
Section 11.4.32, “Rename Filter” for more information.
Statement-based replication will work for most instances, but where your
statements are updating data dynamically within the statement, in fan-in
the information may get increased according to the name of fan-in
masters. Update your configuration file to explicitly use row-based
replication by adding the following to your
binlog-format = row
Triggers can cause problems during fan-in replication if two different statements from each master and replicated to the slave and cause the operations to be triggered multiple times. Tungsten Replication cannot prevent triggers from executing on the concentrator host and there is no way to selectively disable triggers. Check at the trigger level whether you are executing on a master or slave. For more information, see Section C.3.1, “Triggers”.
To create the configuration the masters and services must be specified, the topology specification takes care of the actual configuration:
./tools/tpm install epsilon \ --replication-user=tungsten \ --replication-password=password \ --install-directory=/opt/continuent \ --masters=host1,host2 \ --members=host1,host2,host3 \ --master-services=alpha,beta \ --topology=fan-in \ --start
The description of each of the options is shown below; click the icon to hide this detail:
Click the icon to show a detailed description of each argument.
The user name that will be used to apply replication changes to the database on slaves.
The password that will be used to apply replication changes to the database on slaves.
Directory where Tungsten Replication will be installed.
In a fan-in topology each master supplies information to the fan-in server.
List of all the hosts within the cluster, including the master hosts. The fan-in host will be identified as the host not specified as a master.
A list of the services that will be created, one for each master in the fan-in configuration.
Specifies the topology to be used when creating the replication configuration.
Starts the service once installation is complete.
If the installation process fails, check the output of the
/tmp/tungsten-configure.log file for
more information about the root cause.
Once the installation has been completed, the service will be started and ready to use.