2.1 How can I improve throughput?
2.2 Where should I install replication server?
2.3 Using large raw partitions with Replication Server on Unix.
2.4 How to replicate col = col + 1
2.5 What is the difference between an LTMs an a RepAgent?
2.6 Which Should I choose, RepAgent or LTM?
Check the Obvious
First, ensure that you are only replicating those parts of the system that need to be replicated. Some of this is obvious. Don't replicate any table that does not need to be replicated. Check that you are only replicating the columns you need. Replication is very sophisticated and will allow you to replicate both a subset of the columns as well as a subset of the rows.
Replicate Minimum Columns
Once the replication is set up and synchronised, it is only necessary to replicate those parts of the primary system that actually change. You are only replicating those rows and columns that need to be replicated, but you only need to replicate the actual changes. Check that each replication definition is defined using the clause:
create replication definition rep_def_name
with primary...
...
replicate minimal columns
Second Replication Server
This might be appropriate in a simple environment on systems with spare cycles and limited space on the network. When Sybase replicates from a primary to a replicate using only one replication server the data is transferred across the network uncompressed. However, the communication between two replication servers is compressed. By installing a second replication server it is possible to dramatically reduce the bandwidth needed to replicate your data.
Dedicated Network Card
Obviously, if replication is sharing the same network resources that all of the clients are using, there is the possibility for a bottleneck if the network bandwidth is close to saturation. If a second replication server is not going to cut it since you already have one or there are no spare cycles, then a second network card may be the answer.
First, you will need to configure ASE to listen on two network connections. This is relatively straightforward. There is no change to the client configuration. They all continue to talk to Sybase using the same connection. When defining the replication server, ensure that the interfaces/sql.ini entry that it uses only has the second connection in it. This may involve some jiggery pokery with environment variables, but should be possible, even on NT! You need to be a little careful with network configuration. Sybase will communicate with the two servers on the correct address, but if the underlying operating system believes that both clients and repserver can be serviced by the same card, then it will use the first card that it comes to. So, if you had the situation that all of the clients, ASE and the replication server were on 192.168.1.0, and the host running ASE had two cards onto this same segment, then it would choose to route all packets through the first card. OK, so this is a very simplistic error to correct, but similar things can happen with more convoluted and, superficially, better thought out configurations.
+---------+ +-----------+ +-----------+ | |--> NE(1) --> All Clients... | | | | | Primary | | repserver | | replicate | | |--> NE(2) --------------------->| |-->| | | | | | | | +---------+ +-----------+ +-----------+
So, configure NE(1) to be on 192.168.1.0, say, and NE(2) to be on 192.168.2.0 and all should be well. OK, so my character art is not perfect, but I think that you get the gist!
No Network Card
If RepServer resides on the same physical machine as either the primary or the replicate, it is possible to use the localhost or loopback network device. The loopback device is a network interface that connects back to itself without going through the network interface card. It is almost always uses the IP address 127.0.0.1. So, by applying the technique described above, but instead of using a dedicated network card, you use the loopback device. Obviously, the two servers have to be on the same physical machine or it won't work!
A seemingly trivial question, but one that can cause novices a bit of worry.
There are three answers: on the primary machine, on the replicate machine or on a completely separate machine. There is no right answer, and if you are doing an initial install it probably pays to consider the future, consider the proposed configuration and have a look at the load on the available machines.
It is probably fair to say that replication is not power hungry but neither is it free. If the primary is only just about coping with its current load, then it might be as well looking into hosting it on another machine. The argument applies to the replicate. If you think that network bandwidth may be an issue, and you may have to add a second replication server, you may be better off starting with repserver running on the primary. It is marginally easier to add a repserver to an existing configuration if the first repserver is on the primary.
Remember that a production replication server on Unix will require raw devices for the stable devices and that these can be more than 2GB in size. If you are restricted in the number of raw partitions you have available on a particular machine, then this may have a bearing. See Q2.3.
Installing replication server on its own machine will, of course, introduce all sorts of problems of its own, as well as answering some. The load on the primary or the replicate is reduced considerably, but you are definitely going to add some load to the network. Remember that ASE->Rep and Rep->ASE is uncompressed. It is only Rep->Rep that is compressed.
It is a good practice with production installations of Replication Server on Unix that you use raw partitions for the stable devices. This is for just the same reason that production ASE's use raw partitions. Raw devices can be a maximum of 2GB with replication server up to release 11.5. (I have not checked 12.)
In order to utilise a raw partition that is greater than 2GB in size you can do the following (remember all of the cautionary warnings about trying this sort of stuff out in development first!):
add partition firstpartition on '/dev/rdsk/c0t0d0s0' with size 2024 go add partition secondpartition on '/dev/rdsk/c0t0d0s0' with size 2024 starting at 2048 go
Notice that the initial partition is sized at 2024MB and not 2048. I have not found this in the documentation, but replication certainly seems to have a problem allocating a full 2GB. Interestingly, do the same operation through Rep Server Manager and Sybase central caused no problems at all.
Firstly. While the rule that you never update a primary key may be a philosophical choice in a non-replicated system, it is an architectural requirement of a replicated system.
If you use simple data replication, and your primary table is:
id --- 1 2 3
and you issue a:
update table set id=id+1
Rep server will do this in the replicate:
begin tran update table set id=2 where id=1 update table set id=3 where id=2 update table set id=4 where id=3 commit tran
Hands up all who can see a bit of a problem with this! Remember, repserver doesn't replicate statements, it replicates the results
of statements.
One way to perform this update is to build a stored procedure on both sides that
executes the necessary update and replicate the stored procedure call.
As described in Section 1.2, Log Transfer Managers (LTMs) and RepAgents are the processes that transfer data between ASE and the Replication Server.
LTMs were delivered with the first releases of Replication Server. Each
LTM is a separate process at the operating system level that runs along side ASE
and Replication Server. As with ASE and Replication Server, a RUN_<ltm_server>
and configuration file is required for each LTM. One LTM is required for
each database being replicated.
Along with ASE 11.5 a new concept was introduced, that of RepAgent. I am not sure if you needed to use RepServer 11.5 as well, or whether the RepAgents could talk to earlier versions of Replication Server. Each RepAgent is, in effect, a slot-in replacement for an LTM. However, instead of running as separate operating system process, it runs as a thread within ASE. Pretty much all of the requirements for replication using an LTM apply to the RepAgents. One per database being replicated, etc. but now you do not need to have separate configuration files.
The differences between RepAgents and LTMs are discussed in Section 2.5. Which then to choose. There are pros and cons to both, however, I think that it should be stated up front that RepAgents are the latest offering and I believe that Sybase would expect you you to use that. Certainly the documentation for LTMs is a little buried implying that they do not consider it to be as current as LTMs.
LTM Cons:
LTM Pros:
RepAgent Cons
RepAgent Pros