UPDATE 2013-08-30: Tungsten 2.1.2 was released.
UPDATE 2013-08-23: We have found a few problems that happen when replicating with RBR and temporal columns. We will have to publish an updated bugfix release quite soon.
Tungsten Replicator 2.1.1 is out. Key features in this release are:- A better installer, of which we have already given a preview in tpm, the multi-master composer. The new installer allows faster and more powerful deployments of both single and multiple masters topologies. And it also allows the next feature:
- Secured communication layer. Now the replicator data and administrative messages can be encrypted with SSL across nodes. The security layer, once installed, is transparent. All replication features will keep working as before, and the encryption is independent from the database. In fact, heterogeneous replication (e.g. MySQL to MongoDB, Oracle to MySQL, etc) can use it just as easily as MySQL to MySQL replication.
- Full support for MySQL 5.6 binary log improvements. Now you can have the best of two worlds, running MySQL 5.6 enhanced performance, and Tungsten advanced replication features, without compromises. Due to this improvement, we also have the first change in our transport layer (the Transaction History Logs, or THL) since we released parallel replication. This means that a full cluster upgrade is needed (first slaves, and then masters) if you want to use the new release.
For more information on Tungsten Replicator 2.1.1, see the Release notes.
What does this mean for the common user? Let’s see what you can experience, when installing Tungsten Replicator 2.1.1
$ tar -xzf tungsten-replicator-2.1.1-230.tar.gz
$ cd tungsten-replicator-2.1.1-230
$ export VERBOSE=1
$ ./cookbook/install_master_slave
## -------------------------------------------------------------------------------------
## Installation with deprecated method will resume in 30 seconds - Hit CTRL+C now to abort
## -------------------------------------------------------------------------------------
## WARNING: INSTALLATION WITH tungsten-installer and configure-service IS DEPRECATED
## Future versions of Tungsten Cookbook will only support tpm-based installations
## To install with tpm, please set the variable 'USE_TPM' and start again
## -------------------------------------------------------------------------------------
....5....^C
Installation with tungsten-installer, which has been used until now, is still available, but it is deprecated. We want to encourage everyone to use tpm, as we will stop supporting tungsten-installer from the next release (2.1.2).
The main reason for using tpm instead of tungsten-installer, is that you can now install with security. The Tungsten manual has an extensive section on how to create security certificates. If you are not used to this kind of tasks, you may get discouraged from the very beginning, as you will need to create two key stores, one encrypted password store, and one file with JMX access rules. Tungsten Cookbook to the rescue! It will be enough to state our intention to install using tpm, with security enabled, and the cookbook script will generate the needed files for you.
$ export USE_TPM=1
$ export WITH_SECURITY=1
$ ./cookbook/install_master_slave
Certificate stored in file </home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/client.cer>
Certificate was added to keystore
[Storing /home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/truststore.ts]
Using parameters:
-----------------
password_file.location = /home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/passwords.store
encrypted.password = true
truststore.location = /home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/truststore.ts
truststore.password = cookbookpass
-----------------
Creating non existing file: /home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/passwords.store
User created successfuly: cookbook
Using parameters:
-----------------
password_file.location = /home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/passwords.store
encrypted.password = true
truststore.location = /home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/truststore.ts
truststore.password = cookbookpass
-----------------
User created successfuly: cookbook
# ---------------------------------------------------------------------
# Options for tpm
\
--thl-ssl=true \
--rmi-ssl=true \
--rmi-authentication=true \
--rmi-user=cookbook \
--java-keystore-password=cookbookpass \
--java-truststore-password=cookbookpass \
--java-truststore-path=/home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/truststore.ts \
--java-keystore-path=/home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/keystore.jks \
--java-jmxremote-access-path=/home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/jmxremote.access \
--java-passwordstore-path=/home/tungsten/tinstall/tungsten-replicator-2.1.1-230/cookbook/passwords.store
# ---------------------------------------------------------------------
Next, you will see the complete installation command using tpm, and the cluster will be built as smoothly as it would be without the security additions.
Notice that the paths that you see on the screen are created dynamically. Once installed, the security files will be deployed in a standard location, which will be easily picked up when you need to upgrade.
The difference that you will notice about the secure deployment is only in a few small differences. When using the cookbook tools, you will see a ssl label next to each secured node:
$ ./cookbook/show_cluster
--------------------------------------------------------------------------------------
Topology: 'MASTER_SLAVE'
--------------------------------------------------------------------------------------
# node host1 (ssl)
cookbook [master] seqno: 0 - latency: 0.681 - ONLINE
# node host2 (ssl)
cookbook [slave] seqno: 0 - latency: 1.397 - ONLINE
# node host3 (ssl)
cookbook [slave] seqno: 0 - latency: 1.683 - ONLINE
# node host4 (ssl)
cookbook [slave] seqno: 0 - latency: 1.684 - ONLINE
When using the traditional tools, you will notice one tiny difference in the master URI:
Processing status command...
NAME VALUE
---- -----
appliedLastEventId : mysql-bin.000008:0000000000000427;0
appliedLastSeqno : 0
appliedLatency : 0.681
channels : 1
clusterName : cookbook
currentEventId : mysql-bin.000008:0000000000000427
currentTimeMillis : 1377091602039
dataServerHost : host1
extensions :
latestEpochNumber : 0
masterConnectUri : thls://localhost:/
masterListenUri : thls://host1:2112/
maximumStoredSeqNo : 0
minimumStoredSeqNo : 0
offlineRequests : NONE
pendingError : NONE
pendingErrorCode : NONE
pendingErrorEventId : NONE
pendingErrorSeqno : -1
pendingExceptionMessage: NONE
pipelineSource : /var/lib/mysql
relativeLatency : 656.039
resourcePrecedence : 99
rmiPort : 10000
role : master
seqnoType : java.lang.Long
serviceName : cookbook
serviceType : local
simpleServiceName : cookbook
siteName : default
sourceId : host1
state : ONLINE
timeInStateSeconds : 655.552
transitioningTo :
uptimeSeconds : 656.431
version : Tungsten Replicator 2.1.1 build 230
Finished status command...
Instead of thl:// you see thls://. That’s the indication that the replicators are communicating using a SSL channel.
The same procedure works for multi-master and heterogeneous topologies. In fact, the very same mechanism is used in our commercial product, Continuent Tungsten, where it is installed using the same tools and the same tpm options.
For existing deployments we have a manual page dedicated to Upgrading from tungsten-installer to tpm-based installation. If you are a cookbook user, try
./cookbook/upgrade
There is a live webinar covering many Tungsten-Replicator 2.1.1 features. It is free, on Thursday, August 22nd, at 10am PT.
.
6 comments:
So, now trying to do a pre-install validation, I get errors due to NAT (IPs in /etc/hosts don't match on both sides). Is there any way around this? It shouldn't impede the replication at all should it?
@Sascha,
how hard is to amend /etc/hosts to make entries match? If the same hostname points to different IPs, you will have trouble.
Please post these requests in Tungsten discussion group
Hello,
On a Debian box, one will have trouble with hostname.
Actually, the /etc/hosts:
127.0.0.1 localhost
127.0.1.1 myhostname
and /etc/hostname:
myhostname
Tungsten will beat you hard with that and cannot install.
If you comment 127.0.1.1, then you are in trouble with mysql (cannot connect anymore)
Any suggestion ?
@Larry,
your hostname should point to a real IP address, not the loopback 127.0.0.1. If you don't do that in all nodes, you can't install the replicator. The address is passed from node to node, and if they all point to '127.0.0.1', they will be unable to communicate.
Please post these questions in Tungsten discussion group
Well,
It will work IF you set up your my.cnf (yes, mysql) with the user you plan to use tungsten with.
EG: i plan to use the replication with user toto.
I will have to launch mysql with user toto on Debian/Ubuntu.
Then, the replication works.
Otherwise, you will end with the impossibility to connect your user to user@'' (not a typo, it really annoy you with Host='' !!!).
If anyone found another/better way..
Cheers,
Problem solved.
Wrong permissions.
Just forget about me :)
Post a Comment