In the absence of shared storage between cluster nodes, which two actions can you take to configure a High Availability architecture?

Question

Options

• AMove domain logs to a highly available database.
• BMove server logs to a highly available database.
• CMove transaction logs to a highly available database.
• DMove JMS persistent stores to a highly available database.
• EMove error logs to a highly available database.

• A
  2% (1)
• B
  7% (3)
• C
  81% (35)
• E
  9% (4)

Explanation

In a High Availability cluster without shared storage, surviving nodes must be able to recover critical state from a failed node. Transaction logs (C) record in-flight XA transactions, and without access to them, a surviving node cannot complete or roll back incomplete distributed transactions - making data integrity impossible to guarantee after a failover. JMS persistent stores (D) hold undelivered persistent messages, so if a JMS server fails and its store is local-only, those messages are permanently lost; moving the store to an HA database lets another node take over message delivery seamlessly.

Why the distractors are wrong: Domain logs (A), server logs (B), and error logs (E) are all diagnostic/operational records - they capture what happened, not state that must be recovered. No surviving cluster node needs to read another node's logs to continue serving requests, so making them highly available does nothing for failover capability.

Memory tip: Ask yourself "Does another node need this data to pick up where the failed node left off?" Only transaction logs and JMS persistent stores answer "yes" - everything else is just logging, not recovery state.

No community discussion yet for this question.