Replication is not specifically VLAN aware it just sees 'networks'. If you want a single replication scheme to support multiple different networks then you can use the ROUTE clause (see the documentation for details), Note that this is intended to provide multiple routes for redundancy; the traffic will not use all the routes concurrently. If you want to use both VLANS concurrently for traffic from a single replication then you will need to 'bond' them somehow at the OS level so they appear as one network interface and then configure replication to use that.
If you go down the ROUTE clause path then you can add/modify that in an existing scheme using ALTER REPLICATION.
Thanks for the reply, I have few more queries on this.
1.Using the ROUTE CLAUSE we can use multiple IPs using priority level set, so that if highest priority level set in thr ROUTE clause for the IP is not active it will fall back to the next level priority 2 set IP. But cant we use ROUTE clause to use the multiple route IPs for replication simultaneously?
2. can we execute multiple schema for the same DSN and replication scheme but with different replication route IPs?
At present on my system, I have a replication scheme running for a specific DSN with stand alone Master-Subscriber mechanism, with a specific route IP through VLAN-xxx for replication.
Now I want to create and start another replication scheme for the same DSN and replication mechanism with a different VLAN-yyy route IP to be used for replication in parallel to the existing replication scheme. without making any changes to the pre-existing replication scheme.
for the above scenarios, will there be any specific changes respective to the different replication schema mechanism ie., Active Standby and Standalone Master Subscriber mechanism etc.,
If so what are the steps. like how we need to change the existing schema?
Thanks In advance.
I'm afraid what you want to do is not possible. The ROUTE clause is intended for resilient routing not for enabling multiple network streams concurrently. It is not possible to define multiple replication schemes for the same objects across the same hosts.
Can you share more details on why you want to add a second replication stream so I can see if there is some alternative solution? Is this just to achieve higher performance (replication throughput) or is there some other reason? If you are just looking to increase throughput then you should investigate using TimesTen's parallel replication capability (as long as you are on the 11.2.2 release).
Below is my requirement.
At present we have a working replication scheme (Active Standby and Standalone master Subscriber) working on our platform on a specific network VLAN say VLAN222. now we dont want to use the VLAN222 instead wanted to make use of a new VLAN 333.
We can just add this New VLAN using ROUTE Clause, but until we get the confidence and stability on this New VLAN we want to use the VLAN 222 and VLAN 333 in parallely.
So, Could you please suggest a better solution for me here?
There really is not a solution based purely on TimesTen replication. Your best (only) option is to bond the interfaces at the OS level and monitor the bond and the individual interfaces for traffic carried, errors etc.
Ok Thanks Chris,
One more query,
I want to use 2 network interfaces using ROUTE clause, say 1st IP 188.8.131.52 set to priority 1 and 2nd IP 184.108.40.206 set to priority 2.
Now, how to check the replication routing IP details, if 1st priority set newtork IP fails and the replication carries over the 2nd interface IP 220.127.116.11.
is there any command to check the used/working routing IP address details used for the running replication schema in timesten.
I'd love to be able to say yes but sadly there isn't. We should probably add this to the ttRepAdmin -showstatus output.
I normally use netstat -i to view the traffic on the different interfaces. When replication switches it is pretty obvious (if you have any significant replication traffic going on).
You can also see this from the rep agent connection request messages in the daemon log I believe.
Ok thanks Chris, was helpful. And agree with your point too, in adding as an option in ttrepdaemon -showstatus