Always On? Sybase? You must be kidding…
Well, [SAP] Sybase has always been well known (and coveted) for its replication technology. Sybase Replication Server is a well established, rock-solidly stable product allowing homo- or heterogeneous replication solutions or different types and topologies across most platforms. But as opposed to other DBMS vendors (say Microsoft?) the solution was always kept separate from ASE server.
It looks like SAP has decided to change this at last. ASE 16 SP02 has finally bundled replication server into the core installation package – that is if you purchase the HADR ASE option…
What’s in the package? Let’s have a closer look. The last ISUG issue has a brief description of the solution, but since I have not found an open reference to this document and since the only other option is to read official product documentation I decided to summarize it here for those who do not have access to it.
ASE 16 SP02 came out with quite a few enhancements – Always On falls under the “Availability Enhancement” hood. As the option name suggests Always On has both HA & DR capabilities to choose from. It promises:
- Zero data loss (HA)
- Transparent Client fail-over
- Planned/Unplanned fail-over support
- Soft DB quiesce for planned fail-over without interrupting applications
- Zero downtime upgrades for minor & major DB releases
- Automated fault detection and handling
- Ability to leverage replicate DB in enforced read-only mode with zero user administration
Replication server has most of these capabilities in the past and indeed it is the infrastructure for the Always On option. Yet, having them all bundled together is indeed a huge step forward. I love in particular the transparent fail-over and automated fault detection – forced read only sounds nice too.
As said – the option comes in two configurations: HA & DR.
HA configuration encompasses two database servers tied in synchronous data replication mode (apparently relying on RS 157 SP300 capabilities of synchronous replication) – a pair of ASEs with a pair of dedicated RS applying transaction directly to the companion side with only one node being active at a time:
DR configuration replication mode is a-synchronous (although ISUG specifies otherwise – a typo?..). This is a familiar topology we have been used with Sybase Replication Server for years – a pair of ASEs each with a dedicated RS connected through a direct route to speed up message delivery to the companion side:
I am very curious how simple the management of HADR option is and how scalable is the topology behind it. I’ve been busy testing replication server for the last couple of months (replicating from an old ASE 15.x release to a new ASE 16 SP01PL2 in either direction). Although the setup part is pretty easy, one of the hurdles I have been stumbling on was the volume of data transferred between various RS components. In particular the pressure on the inbound queue. In the HA configuration above the RS responsible for applying transaction to the companion ASE seems to be sitting close to the companion ASE rather than the primary ASE.
As of today when replication agent follows transactions from the primary log to the inbound queue it translates each update/delete command into a command listing all of the primary table columns. For wide tables this impacts the volume of data moved across network pretty badly (we’ve lodged CR to deal with this – CR791846). As minimal column support kicks in only for the outbound queue I am very curious to see what the out-of-the-box HA implementation is able to achieve (unless it is based on stream replication rather than transaction replication). In the testing I have been performing any latency introduced to the chain RA – inQ was threatening to blow the primary ASE transaction log – the nightmare for any DBA messing up with replication server. And I have not been testing synchronous replication even! I also wonder if HADR option includes various ASO enhancements introduced into RS for the past couple of years.
In short, HADR is our there – love it or leave it.
I hope we will go with the former but only time will tell…
ps. I wonder what are the pricing differences between HADR option vs. RS CORE (+ASO).