cancel
Showing results for 
Search instead for 
Did you mean: 

Replication server on linux

Former Member
0 Kudos

Hi Folks

We are planning on using Replication server in our Env.

Is it possible to run  Replication on Linux ( Red Hat ) and primary and secondary on IBM power 7 on Unix Aix platform.

Regards and Thanks

RK

Former Member
0 Kudos

We are planning on moving data from primary ASE(NJ) to Secondary ASE(MN) . Is one  Rep server is fine or do we need more since distance is more than 1000 miles .

Between RSSD and eRssd when do you use one over the other ?

former_member89972
Active Contributor
0 Kudos

One RS should suffice if it is just two ASE servers involved.

If you use two RSs then you will need to set-up "route" for the data to flow between RS to RS.

For the RS the distance matters only to the extent that it will introduce some latency due the sheer distance.

eRSSD is my preference for the least amount of maintenance needed and straight forward simple replication.

Having said that eRSSD has slightly different flavor of ASA T-SQL,  so be prepared to live with that.

HTH

Avinash

Mark_A_Parsons
Contributor
0 Kudos

One RS should be sufficient as long as you keep in mind:

- having the RS co-located with the PDS ensures txns are pulled from the PDS as quickly as possible; this can come in handy if the PDS goes down (ie, you want to minimize the number of txns that could get stranded in the PDB)

- if you use an ASE to house the RSSD, you definitely want the ASE/RSSD co-located with the RS

- 2x RSs (running on different hosts) are going to require additional licenses; if you have limited licenses then you'll likely be limited to running a single RS; on the other hand, if you have the additional licenses, setting up x2 RSs (one co-located with PDS; one co-located with RDS; route between the 2 RSs) would provide some extra benefits (reduced latency for RS/DSI -> RDB; access to a 'local' RS in both locations for other RS work, etc)

-------------

As for ASE/RSSD vs eRSSD ... to date, everywhere I've worked (to include a couple dozen clients) has used ASE/RSSD ... no eRSSDs used (so far).  Primary reason being that DBAs are already familiar with ASE, while SQLAnywhere (eRSSD) requires some additional training/knowledge; also, DBAs can re-use all of their ASE-based scripting (monitoring, maintenance, etc) as opposed to having to come up with some new scripts for SQLAnywhere.

Former Member
0 Kudos

Is it Possible to have One  Rep server RS1 to have multiple primary to corresponding Secondary ?

PS1 - SS1

PS2 - SS2

Thanks And Regards

RK

former_member194571
Active Participant
0 Kudos

Hi RK,

yes. The relation between databases and RepServer instances is many to one. A database must be controlled by exactly one Replication Server (regrdless of its role as primary or replicate - I guess that's what you mean as "secondary"). A single RepServer can control multiple databases. Just keep in mind that SAP recommends connections between DB servers and RepServers (in either direction) to be LAN connections. If there's WAN between primary and replicate DB, this part should be covered by a route / a RepServer-to-RepServer connection.

Out of own experience, I generally recommend to take thr first steps on RepServer with somebody (maybe a consultant) onsite who is not doing this for the first time.

As for the RSSD / ERSSD question: I agree with Mark's answer if ASE is involved anywhere. Recently, there have been quite some RepServer deployments w/out ASE involved (mostly from a 3rd party system to HANA) where nobody will run an ASE just for RSSD. And even with ASE part of the scenario, the ERSSD is usually on the RepServer machine, consuming few resources and reducing complexity. I think if you feel comfortable with one or the other option, there is no strong reason not to use it.

HTH

Volker

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member89972
Active Contributor
0 Kudos

Yes it is possible. 

Suggested best practice is to keep the environments of the same OS flavor to avoid conversions if any and also support issue to avoid vendors doing finger pointing when you face issues.

Any specific reason(s)  that you want to select this path ?

HTH

Avinash