Which OpenLDAP high availability design fits your directory
If your directory cannot go down, choose mirror mode when one writer at a time is acceptable and you want a hot standby behind a load balancer, and choose N-Way Multi-Provider when you need high availability across sites and your team accepts the consistency trade-offs that come with every provider accepting writes. Mirror mode keeps single-provider consistency: two providers replicate from each other, while an external frontend sends all writes to one of them. That design needs an external proxy or load balancer to route traffic, so the proxy is part of your availability plan, not an afterthought. Multi-provider replication suits providers spread across sites, but the OpenLDAP 2.6 Administrator's Guide is explicit that it has nothing to do with load balancing, because every provider handles the same write load. Do not select it to spread read or write traffic.
Multi-provider replication carries the costs the guide warns about. It breaks the data consistency guarantees of the directory model, it needs tightly synchronized clocks and unique server IDs on every node, and during a network partition it may be best to deny writes to partitioned clients. Before you commit, confirm with your own architects how your applications behave when two sites accept conflicting changes, who owns conflict resolution, and how clock drift is monitored. Test partition behavior in a lab that mirrors your network, and write down the rule for which side keeps accepting writes. If nobody on your team can state that rule, mirror mode is the safer starting point.
Delta-syncrepl is a consumer-side choice that applies to either design. It replicates from a changelog, which suits directories with many objects receiving small changes, but it is incompatible with partial replication, and the accesslog database must never be replicated. Decide it per consumer, not per topology, and confirm the consumer configuration with your vendor or engineer before go-live. The OpenLDAP 2.6 Administrator's Guide on replication covers the configuration keys and warnings you will need to check against your chosen design.
Mirror mode and multi-provider compared on the factors that matter
This table compares OpenLDAP mirror mode and N-Way Multi-Provider replication on the factors that decide a high availability design, including consistency, write handling, partitions and operating effort. Read each row with its condition, since the right choice depends on whether you run one site or several and how much write risk you can accept.
| Factor | Mirror mode with hot standby | N-Way Multi-Provider across sites | When the difference matters |
|---|---|---|---|
| Consistency model | Single-provider consistency is kept because all writes go to one active provider at a time | Breaks the data consistency guarantees of the directory model, according to the OpenLDAP guide | Matters for any application that expects a write to be visible immediately on every read path |
| Write path | An external frontend sends all writes to one of the two mirrored providers | Every provider accepts writes, so each provider carries the same write load | Matters if your application or tooling cannot tolerate conflicting writes landing on different servers |
| Load balancing | Not the purpose of the design, but the external proxy or load balancer is required to route traffic | The guide says it has nothing to do with load balancing because every provider handles the same write load | Matters if you expect read or write scaling from a second server; neither design is a scaling answer for writes |
| External proxy or load balancer | Required, to direct writes to the active provider and fail over to the standby | Not described as required by the guide, but clients must still be pointed at providers across sites | Confirm how your proxy health checks and failover will behave before you rely on the standby |
| Behavior during network partitions | Only one provider receives writes, which limits divergence during a split | The guide says it may be best to deny writes to partitioned clients | Matters most when sites can lose connectivity for extended periods and writes continue on both sides |
| Clock and server ID rules | Still needs unique server IDs; the guide does not present tight clock sync as the central risk here | Requires tightly synchronized clocks and unique server IDs across every provider | Matters when sites use different time sources or when servers are cloned from one image without changing identifiers |
| Site placement | Suits a pair in one location or a standby in a second site with an active-passive pattern | Suits high availability with providers spread across sites where a single point of failure is not acceptable | Matters when a regional outage must not stop directory writes, and your team can run conflict-aware operations |
| Operating effort | Lower: one write target, a proxy and a standby to test; confirm failover runbooks with your team | Higher: clock discipline, server ID governance, partition handling and monitoring of every provider | Matters for small teams; ask any implementation partner to scope testing of partition and recovery scenarios in writing |
How the two topologies are built
Both designs give OpenLDAP a second provider, but they place writes, proxies and change feeds in different spots. The cards below show which component does what, so you can see where a failover or partition problem will land before you pick one.
Mirror mode provider pair
Two providers replicate from each other, but only one accepts writes at a time. The second provider is a hot standby that takes over when the first fails. Because one node is the write authority, the directory keeps single-provider consistency. Check how you will promote the standby and how you will bring the failed node back without losing changes.
External frontend sends all writes
In mirror mode, an external frontend, such as a proxy or load balancer, is what sends every write to one provider. OpenLDAP itself does not do this routing. Your design depends on this component, so it must detect failure and switch writes to the standby. Confirm which product you will use and how it health-checks the providers.
N-Way Multi-Provider writes everywhere
In N-Way Multi-Provider replication, every provider accepts writes and replicates them to the others. The design targets high availability and providers spread across sites. The OpenLDAP guide states it is not a load balancing feature, because each provider handles the same write load. Plan for conflicting updates made on different providers during a partition.
Consumers attach to providers
Consumers are read-only replicas that pull changes from a provider, and they can be placed close to applications or in other sites. Their role is read scale and local lookup, not write handling. In either topology, decide which provider each consumer follows and what happens to it when that provider is down.
Delta-syncrepl reads a changelog
Delta-syncrepl lets a consumer replicate from a changelog rather than comparing whole entries. It suits directories with many objects that receive small changes. It is incompatible with partial replication, so any consumer that needs only a subset of the tree cannot use it. Confirm that your consumers need the full tree before you choose it.
Accesslog database stays unreplicated
The accesslog database holds the change history that delta-syncrepl reads. The OpenLDAP guide says it must never be replicated. Treat it as local state on each provider, back it up separately if you need it, and check its size and purge settings during capacity planning.
What happens to consistency when a network partition splits the sites
Mirror mode keeps single-provider consistency because every write lands on one node. Two providers replicate from each other, but an external frontend, usually a proxy or load balancer, sends all writes to the active one while the other stays a hot standby. When the sites split, the consistency question stops being about conflicting writes and becomes a failover question: does the frontend still reach the active provider, and does the standby promote cleanly once it is needed? Your team has to decide which side of a split keeps accepting writes, how the frontend health checks decide that, and what a human does when the two sites disagree about which provider is live. The OpenLDAP 2.6 Administrator's Guide describes the topology in its replication chapter, and that is the place to check the exact frontend requirements before you design around them.
Multi-provider replication is a different trade. The Administrator's Guide warns that it breaks the data consistency guarantees of the directory model, that it needs tightly synchronized clocks and unique server IDs, and that during network partitions it may be best to deny writes to partitioned clients. In practice, that means a site cut off from its peers can keep accepting writes that conflict with changes made elsewhere, and those conflicts are resolved by replication rules you must understand before go-live. Denying writes on the isolated side protects consistency but turns a network fault into an outage for users at that site, so the availability you gain across sites is partly traded away during exactly the events you are designing for.
Before you choose, run a partition test in a staging copy of your topology. Cut the link between sites under a realistic write load, make the same attribute change on both sides, then restore the link and check what the directory holds. Confirm whether your clients can be configured to refuse writes when they lose their peers, how long a site can run before someone notices, and who has authority to re-enable writes. Ask your DeployOpen or vendor contact to document the expected behavior for your clock sources and server IDs, and treat any result you cannot reproduce as a blocker rather than a footnote.
Clock and server ID rules that break multi-provider setups
Multi-provider replication puts every site in a position to accept writes, so the rules for time and identity apply to each provider equally. Clock drift, duplicate server IDs and partition behavior each cause a different failure, and each needs a named owner before production traffic arrives. The four cards below set out what the OpenLDAP documentation requires and what your own teams must confirm.
Tightly synchronized clocks required
Multi-provider replication depends on tightly synchronized clocks on every provider, according to the OpenLDAP 2.6 Administrator's Guide. Replicated changes carry timestamps that providers use to order updates, so drift between sites can reorder writes in ways no operator sees directly. Ask your time management team which sources each site uses, how drift is measured and who gets alerted when a node falls out of tolerance. Confirm that monitoring covers standby sites that rarely take writes.
Unique server IDs per provider
Every provider in a multi-provider group needs a unique server ID, set in the slapd configuration as olcServerID. Two providers sharing an ID, often because a server was cloned from a template or disk image, leave replication unable to identify where changes originated. Record each ID in your configuration management inventory, and confirm that new nodes and rebuilt virtual machines receive a fresh value before they join the group.
Conflicting writes across sites
Multi-provider replication lets any site accept writes, so a network partition can produce conflicting writes to the same entry from two sides. The guide warns that this breaks the data consistency guarantees of the directory model, and suggests that during partitions it may be best to deny writes to partitioned clients. Mirror mode avoids this by sending all writes to one provider, at the cost of an external proxy and a failover step. Ask which sites can write during a partition and who makes that call.
Checks before go-live
Test the design before production users depend on it. Cut the link between sites, confirm which side refuses writes, then restore the link and check that both sides converge to the same entries. Verify clock synchronization and server ID uniqueness on every node, and rehearse failover with the staff who will run it. Keep the results as dated evidence, since auditors and your own change board will ask how the design was proven.
When delta-syncrepl fits a consumer and when it does not
Delta-syncrepl replicates from a changelog instead of re-reading the content of the directory on each pass, so it is designed for a consumer that holds many entries while only a small share changes between synchronizations. A directory with a large user population, where logins, group membership tweaks and attribute updates arrive steadily, is the usual case where the changelog approach pays off. The OpenLDAP documentation describes it as suited to exactly this pattern of many objects with small changes.
- Change volume: the benefit depends on the ratio of changed entries to total entries. A consumer that is mostly idle between synchronizations gains the most.
- Consumer count: each consumer runs its own synchronization against the provider, so the load on the provider grows with the number of consumers.
- Changelog retention: the changelog must be kept long enough for consumers to catch up after an outage, so the retention setting is part of the design.
- Verification: compare entry counts and sample attributes between provider and consumer after cutover and after a simulated outage.
- Illustrative example: a directory of 200,000 user entries where a few hundred change daily is a profile that fits the changelog model well.
Confirm the changelog retention, the expected change rate and the consumer count with your directory team before you commit to this design, and ask the implementation partner to show the verification steps in the written scope.
Partial replication sends a consumer only a subset of the directory, such as one branch, one set of attributes or one business unit's users, because the consumer is local to an application or a site with narrow needs. The OpenLDAP documentation states that delta-syncrepl is incompatible with partial replication, so this situation calls for a different consumer configuration. The mismatch matters most when the subset is defined by filters that change over time, because the consumer must still receive the right entries.
- Hard incompatibility: delta-syncrepl cannot be used for a consumer that receives only part of the directory. Plan the filter design before you choose the replication mode.
- Filter drift: a consumer whose filter scope changes later needs a review of the replication configuration, not just a change to the filter.
- Application scope: many single-application consumers need only a handful of attributes, which often points to a narrower design than a full mirror.
- Testing: verify that entries entering and leaving the filter scope reach the consumer correctly, including moves between branches.
- Illustrative example: a regional site that should hold only its own users is a partial replication case, and a standard delta-syncrepl consumer would not meet that requirement.
Ask the vendor or your OpenLDAP specialist to confirm in writing whether the planned consumer design requires partial replication, because that answer determines whether delta-syncrepl is available at all.
Delta-syncrepl depends on an accesslog database that records changes, and the OpenLDAP documentation is firm that this database must never be replicated. Treating it like ordinary directory data would copy change history into places it was never meant to go, and it can corrupt the replication logic on the receiving side. This rule applies to every consumer design and to every provider, whatever topology sits above them.
- Never replicate: the accesslog database itself is excluded from replication in every configuration.
- Separate storage: keep the accesslog as its own local database on each server that produces the changelog.
- Backup handling: include the accesslog in backup planning as a local artifact, and confirm that restores do not overwrite a live consumer with stale change history.
- Audit relevance: change history can contain sensitive attribute values, so it needs the same access controls as the directory it records.
- Review step: check configuration files and overlay settings during every change review, since an accidental replication of the accesslog is easy to miss.
Before go-live, ask your implementation partner to show the configuration that excludes the accesslog from replication and the test that proves it, and record that check as evidence for your change control process.
The choice of consumer replication mode is separate from the choice between mirror mode and N-Way Multi-Provider, because consumers attach to whichever provider is current. A consumer decision made from its own data shape, filter needs and change rate will hold whether the provider pair is a hot standby behind a load balancer or a multi-provider set spread across sites. Keeping the two decisions apart makes each easier to review with auditors and architects.
- Consumer inputs: entry count, change rate, filter scope and attribute footprint drive the consumer decision.
- Provider inputs: consistency needs, partition behavior and write placement drive the provider decision.
- Failover behavior: confirm that a consumer can re-point to another provider after failover without losing its place.
- Documentation: record the consumer mode and its reason in the same design document, but in its own section.
- Illustrative example: a read-heavy application consumer may be built the same way whether the provider design is mirror mode or multi-provider.
When you request a quote, ask for the consumer design to be described separately from the provider design, with its own tests and sign-off, so a later topology change does not force a rebuild of every consumer.
Operating each design: upgrades, backups, monitoring and skills
This table compares what each OpenLDAP high availability design asks of your team after go-live: upgrades, backups, replication monitoring and skills. Read it as a checklist of questions to put to your implementer and your own staff, since the operating load depends on your sites and tooling. The main takeaway is that mirror mode concentrates operations on one writable node, while multi-provider replication spreads write-path risk across every provider.
| Operating area | Mirror mode with hot standby | N-Way Multi-Provider across sites |
|---|---|---|
| Upgrade sequencing | Upgrade the standby first, fail writes over, then upgrade the former active node. Confirm the order against the project documentation for your release line. | Every provider runs the same write path, so mixed-version periods need explicit planning. Confirm supported version mixing in the OpenLDAP 2.6 guide before scheduling. |
| Current release lines | Feature release 2.7.1 or long term support release 2.6.15. Choose the line before building the pair, and confirm its support window. | Same release choice applies to every provider. Keep all providers on one line where possible to simplify testing. |
| Backup approach | Back up the active provider and test restores on the standby. Confirm how replication state is handled when restoring a node. | Back up each provider independently. A restore can reintroduce stale data that replication then propagates, so confirm the restore procedure with your implementer. |
| Restore testing | Rehearse failover and restore together, so the standby can be promoted with a known data state. | Rehearse restoring one provider while others stay live, including server ID and clock checks on rejoin. |
| Replication lag monitoring | Watch the lag between the two mirrored providers and the frontend's write target. Mirror mode has one write path to observe. | Watch lag and conflicts between every pair of providers. Lag can be hidden by partitions, so alert on divergence, not only on delay. |
| Provider health | Track the health of the active node, the standby and the external proxy or load balancer that routes writes. | Track each provider's health and reachability from each site. Provider failures are less visible without a central write point. |
| Clock and server ID hygiene | Confirm clock sync on two nodes and unique server IDs. Mistakes here are easier to spot in a pair. | Confirm tightly synchronized clocks and unique server IDs on every provider. Add checks to configuration management so drift is caught early. |
| Skills needed | Staff who can run OpenLDAP configuration, the external load balancer and failover runbooks. Confirm the skills gap with your implementer. | Staff who understand multi-master consistency, partition handling and conflict resolution across sites. The skills bar is generally higher. |
| Who is paid for what | Implementation and runbook work are typically a one-time quote. Ongoing monitoring and upgrades can recur under a retainer. Ask for each item in writing. | Multi-site design, testing and partition runbooks add scope to the one-time quote. Ask whether upgrades and testing recur. |
How to choose and test a design before production
This sequence turns the mirror mode and multi-provider choice into a tested decision, so the team knows which failure modes the design survives, what happens to writes during a partition, and how failover behaves before real users depend on it. The output is a documented topology, a set of drill results and a sign-off record that the operations team can run against.
Define the failure modes to survive
Start by listing the failures the directory must survive: loss of one server, loss of a whole site, a WAN link failure between sites, and a bad change replicated to every copy. Assign each one an owner in the identity team and a yes or no answer for whether service must continue during it. Done means a signed list that names the failures, the expected behavior for each, and the applications that depend on the directory. This list is the test plan, so every later step must trace back to it.
Decide whether sites must accept writes
Decide whether each site must keep accepting writes when it is cut off from the others. If it must, multi-provider replication is the candidate, and the team must accept the consistency trade-offs the OpenLDAP 2.6 Administrator's Guide describes. If writes can wait for a single write point, mirror mode behind a load balancer keeps single-provider consistency with a hot standby. Record the decision, the business owner who accepted it and the write behavior each application expects during a partition. Confirm the answer with the application owners, not only with the directory team.
Verify clock sync and server ID controls
Multi-provider replication requires tightly synchronized clocks and unique server IDs, so check both before building anything. Confirm that every provider syncs to the same time sources, record the measured offset on each host and set an alert threshold your team agrees on. Check that each
serverIDvalue is unique across the topology and documented in a configuration inventory. Done means a dated report from each host showing its time source and its configured server ID, reviewed by someone outside the build team.Build a test replication topology
Build a non-production copy of the chosen design with the same OpenLDAP version, overlays, TLS settings and replication agreements planned for production. For mirror mode, configure the two providers, the external proxy or load balancer and at least one consumer. For multi-provider, configure each site's provider and its agreements. If delta-syncrepl is used for consumers, confirm the accesslog database is excluded from replication and that partial replication is not configured. Done means a replication status check shows every agreement current, and a seed dataset with representative object counts loads cleanly on every node.
Run failover and partition drills
Run each drill from the failure list against the test topology: stop one provider, cut the network link between sites, write to both sides during the cut, then restore the link. For mirror mode, confirm the frontend moves writes to the standby and that clients reconnect without manual edits. For multi-provider, record which writes conflict after reconnection and whether the chosen policy denies writes on partitioned clients. Log each drill with start time, observed behavior and data differences found by comparing the directory on each side. Done means every drill has a recorded result and a named owner for any gap.
Document the design and sign off
Write the operations runbook from the test results: topology diagram, server IDs, time sources, load balancer configuration, the write policy during partitions, the recovery steps for each drill and the monitoring that detects replication lag. Ask the vendor or your support provider to confirm any behavior the drills did not cover, and record that answer in the runbook. Done means the runbook is approved by the identity, platform and application owners, and the drill results are kept with it for the next change review and the next audit cycle.
Questions buyers ask before choosing an OpenLDAP replication design
Is mirror mode enough for a single site?
Often yes, if the goal is high availability for one site and not load distribution. Mirror mode keeps two providers replicating from each other while an external frontend sends all writes to one of them, so consistency stays with a single provider and a second server can take over. The design depends on a proxy or load balancer that health-checks the providers and fails writes over correctly. Confirm how your application handles failover, whether reads can tolerate brief lag, and who owns the load balancer configuration. A single-site design still fails if the site or its network fails, so check whether the business accepts that exposure before choosing it.
Does multi-provider replication work as a load balancer?
No. The OpenLDAP Administrator's Guide states that N-Way Multi-Provider replication is for high availability and for providers spread across sites, and that it has nothing to do with load balancing, because every provider handles the same write load. Choose it when a single point of failure is unacceptable and writes must continue at more than one location. If the aim is spreading read traffic, a proxy such as lloadd or a separate consumer design is the better fit, and you should confirm that choice against your own topology.
What does the team need in clock management and monitoring?
Multi-provider replication needs tightly synchronized clocks and a unique server ID on every provider, and the guide warns that it breaks the data consistency guarantees of the directory model. Your team needs a time source that all providers use, alerting on clock drift, and a documented process for adding or changing server IDs. Monitoring should cover replication lag, conflicts, and whether each provider's contextCSN values are advancing. Ask whether your staff already run this kind of monitoring for other distributed systems, because the work is ongoing, not a one-time setup.
Can our team run an OpenLDAP replication design internally?
It depends on existing skills in LDAP schema, ACLs, TLS certificates, replication configuration and failure recovery. A team that already operates OpenLDAP and has tested failover can take on mirror mode with a clear runbook. Multi-provider across sites adds partition handling, where the guide suggests it may be best to deny writes to partitioned clients, and that decision needs a documented owner and a rehearsed procedure. Assess who is on call, whether backups and restore tests exist, and how upgrades between the 2.6 LTS and 2.7 lines will be tested. DeployOpen plans, implements, documents and supports self-hosted platforms in your infrastructure under a written scope, so an engagement can cover design, build and handover, or the team can keep it in-house.
What drives the cost and effort of an OpenLDAP replication design up or down?
The main drivers are the number of sites, the number of providers, whether writes must continue during a partition, how many applications depend on the directory, and how mature your monitoring and change control are. Costs are one-time for design, build, testing and documentation, and recurring for monitoring, patching, backup testing and on-call time. Internal staff time is usually the largest component, even though the software is open source under the OpenLDAP Public License. Cost goes down when the topology is simple, the team has rehearsed failover, and clock and server ID rules are enforced by automation. It goes up with each additional site and each unresolved consistency question.
What should we ask for in a quote for this work?
Ask for a written scope that names the topology, the number of providers and sites, the load balancer or proxy to be configured, and the clock and server ID standards to be applied. Request deliverables for the replication configuration, a failover and partition runbook, monitoring checks, backup and restore testing, and handover training. Confirm what is excluded, such as application changes, migration of existing data, or ongoing support, and whether a retainer covers upgrades. Also ask who performs the testing and what evidence you receive. Compare quotes on this written scope, not on headline effort.
How does delta-syncrepl change the replication picture?
Delta-syncrepl replicates from a changelog and suits directories with many objects that receive small changes, which can reduce replication traffic compared with replaying full entries. It does not change the high availability model by itself, so you still choose mirror mode or multi-provider for failover. Two constraints apply: it is incompatible with partial replication, and the accesslog database must never be replicated. Confirm your object churn pattern, whether any consumer needs partial replication, and how the accesslog database is excluded from replication before you adopt it.
What to ask for in a scoped quote
Ask for a quote that prices each piece of work separately: the design of the topology, the build of the two or more providers and any load balancer or proxy in front of them, the testing of failover and partition behavior, the written documentation, and the handover to your operations team. Mirror mode and N-Way Multi-Provider differ most in the design and failure-testing steps, because mirror mode needs a frontend that routes writes to one provider while multi-provider replication needs a plan for conflicting writes, clock drift and the serverID values on every node. A quote that lumps these together makes it hard to see which decision drives the cost. DeployOpen does not publish a price list, so a quote follows from the scope you agree in writing before any work starts, and that written scope should name the deliverables, the environments covered and the acceptance tests.
Separate one-time work from recurring support in the same document. One-time work covers the initial design, the build, the partition and failover tests, the runbooks and the handover. Recurring support covers patching the OpenLDAP packages, monitoring replication lag, reviewing clock synchronization, and rerunning failover tests after configuration changes. Ask whether ongoing support, upgrades and continuous testing are offered as a retainer, what it includes, and how it is priced against the one-time scope. Also ask which OpenLDAP line the work targets, since the current releases are 2.7.1 and the long term support release 2.6.15, and whether the chosen line has a support window your organization can accept.
Confirm what is excluded before you sign. Common gaps include the hardware or cloud resources, the external load balancer or proxy, certificate issuance, the monitoring stack and the application-side changes needed to point clients at a new address. Ask for the test plan that will prove the design, including a written decision on whether writes are denied to a partitioned site, which the OpenLDAP Administrator's Guide raises as an option for multi-provider designs. Your own team should confirm its internal responsibilities in the same scope, such as who approves changes and who holds the on-call rota after handover. A scope that names these owners in advance keeps the quote comparable with other bids.
How DeployOpen scopes, delivers and supports OpenLDAP high availability
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an OpenLDAP high availability design is built in your environment and handed over to your team. We start by agreeing which failure modes matter to your directory before choosing between mirror mode and multi-provider replication.
How we scope
- Engagements are fixed-scope, with the design, deliverables and timeline agreed in writing before work starts.
- The written scope states which applications depend on the directory and which consistency and partition behavior they can tolerate.
- Scope records the sites, network links, clock sources and server ID plan the design must respect.
- Scope names the replication topology, load balancer or proxy role and any delta-syncrepl consumers included.
How we build
- We configure the chosen topology in your cloud accounts, data centers or air-gapped network, not on shared infrastructure.
- Build work covers TLS, certificate handling, unique server IDs and clock synchronization checks on every provider.
- For mirror mode, we set up the external proxy or load balancer so all writes reach one active provider.
- We test failover, provider restarts and simulated partitions against the behavior agreed in the scope.
How we hand over
- Handover documents the replication topology, server IDs, clock rules and the write path your applications must use.
- Runbooks describe how to promote a standby, rebuild a consumer and recover after a partition, including when to deny writes.
- We document the accesslog rules for delta-syncrepl, including that the accesslog database must never be replicated.
- Your team receives evidence of tests run, configuration baselines and open risks to confirm with your own administrators.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover OpenLDAP upgrades between the 2.6 long term support and 2.7 feature release lines, after a written impact review.
- Support can include periodic failover tests and checks that clocks and server IDs still match the documented design.
- Ask any provider, including DeployOpen, to confirm in writing which versions, support windows and responsibilities apply to you.
