Skip to content

W-23431158-hadr-restructure-kt#453

Open
kevintroller wants to merge 6 commits into
latestfrom
W-23431158-hadr-restructure-kt
Open

W-23431158-hadr-restructure-kt#453
kevintroller wants to merge 6 commits into
latestfrom
W-23431158-hadr-restructure-kt

Conversation

@kevintroller

Copy link
Copy Markdown
Contributor

Summary

Part of the HA/DR documentation restructure (GUS W-23431158). This repo hosts two deployment models, so both changes ship in one PR.

  • New page: hybrid-standalone/.../hybrid-standalone-hadr.adoc covering clustering-based HA (shared memory, automatic failover), shared-responsibility DR, and clustered-topology considerations (concurrent-restart caution, cluster rejoin, Object Store persistence/lock caveats). Added to the Hybrid Standalone nav.
  • CloudHub 2.0 (cloudhub-2/.../ch2-ha-dr.adoc): added a top-of-page pointer to the Mule Runtime HA/DR hub for a consistent cross-deployment experience. Existing content unchanged.

Related PRs (same effort, one branch name per repo)

  • docs-mule-runtime: HA/DR hub
  • docs-runtime-manager: CloudHub page hub link
  • docs-runtime-fabric: new Runtime Fabric page

Notes

  • The Hybrid Standalone page includes field/support-sourced operational guidance that should be validated by SMEs before merge.

Test plan

  • Antora build resolves cross-repo xrefs (hub, mule-runtime HA clusters)
  • New page appears in the Hybrid Standalone nav

Made with Cursor

… the hub

Create a Hybrid Standalone High Availability and Disaster Recovery page
covering clustering-based HA, shared-responsibility DR, and clustered-topology
considerations, and add it to the nav. Add a hub pointer to the CloudHub 2.0
HA/DR page for a consistent cross-deployment experience.

Co-authored-by: Cursor <cursoragent@cursor.com>
@kevintroller
kevintroller requested a review from a team as a code owner July 13, 2026 21:29
kevintroller and others added 5 commits July 13, 2026 18:44
… the shared skeleton

Co-authored-by: Cursor <cursoragent@cursor.com>
…or AI retrieval

Co-authored-by: Cursor <cursoragent@cursor.com>
….0 and Hybrid Standalone HA/DR pages

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…stances

Move the hybrid-standalone-hadr page from a top-level nav item to a child of
Managing Hybrid Standalone Instances (after Managing Clusters) and add a
matching entry to the managing-hybrid-standalone index page.

Co-authored-by: Cursor <cursoragent@cursor.com>
@kevintroller kevintroller changed the title W-23431158: Add Hybrid Standalone HA/DR page and link CloudHub 2.0 to the hub W-23431158-hadr-restructure-kt Jul 14, 2026
=== Considerations for Disaster Recovery Implementations

Implementing a Disaster Recovery (DR) strategy for applications deployed to CloudHub 2.0 requires careful consideration of several key factors.
A DR strategy for applications deployed to CloudHub 2.0 requires you to weigh several factors.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A DR strategy for applications deployed to CloudHub 2.0 requires you to weigh several factors.
A DR strategy for applications deployed to CloudHub 2.0 requires you to consider several factors.

=== Considerations for Disaster Recovery Implementations

Implementing a Disaster Recovery (DR) strategy for applications deployed to CloudHub 2.0 requires careful consideration of several key factors.
A DR strategy for applications deployed to CloudHub 2.0 requires you to weigh several factors.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per our standards, we should avoid using "weigh" here, because it can be interpreted differently. Use the simpler term, which is "consider".

The Anypoint Control Plane encompasses additional Anypoint services apart from CloudHub 2.0. For more details, refer to the https://compliance.salesforce.com/en/documents/a005A00000vvLBjQAM[DR Test Summary].
* Keep your integrations stateless.
* Don't share transactional information between client invocations or scheduled executions.
* When the middleware must retain data because of a system limitation, persist it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* When the middleware must retain data because of a system limitation, persist it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory.
* If the middleware must retain data because of a system limitation, persist it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants