Symantec Privileged Access Management

 View Only

 PAM Cluster: Concerns on Reboot and Log Reduction Procedure during Replication Warning

MARUBUN SUPPORT's profile image
MARUBUN SUPPORT posted Dec 12, 2025 04:54 AM

Hi Team,

Product
PAM

Situation Description

A customer is operating a PAM (Privileged Access Management) cluster with two member servers.

While the cluster is running (clustered state), the replication status is as follows:

PAM Server 1: △ (The icon shows a yellow triangle with an exclamation mark.)
PAM Server 2: 〇 (Circle Green)

Only PAM Server 2 is currently accessible via the PAM management console, 
indicating that PAM Server 2 is acting as the Primary server.

Proposed Action

Our current thought is to reboot PAM Server 1 in an attempt to restore its connectivity to the PAM management console.
Once connected to the PAM management console from PAM Server 1, we plan to execute the "Log Reduction" procedure.

Questions

1. Is there a possibility of data inconsistency (data misalignment) occurring between 
   PAM Server 1 and PAM Server 2 if we perform the "Log Reduction" procedure from PAM 
   Server 1 in this current state?

2. There is a difference in the "/" (root) partition capacity between PAM Server 1 
   and PAM Server 2. What is your recommendation on how to best delete files to reduce the disk usage?

Thanks,

Ralf Prigl's profile image
Broadcom Employee Ralf Prigl

Hello, PAM actually has a Management Console, but from your description what you refer to as the management console seems to be just the PAM user interface (UI). Is that correct? The problem description and proposed action don't make much sense as is. Also, what is the "Log Reduction" procedure you are referring to? PAM is a closed appliance, you cannot delete files to reduce disk usage. Given that you have nodes with different disk size, I assume these are virtual appliances, in which case you would be able to increase the disk size. If a 2-node cluster goes out of sync, normally the only way to recover is to stop and start the cluster, assuming the cause of the problem was something temporary, and not a new condition that prevents communication between the two nodes now. Even in a situation where one node is rebooted and recovers, it would get the database from the other node, there would be no inconsistency afterwards. Mysql database replication protects against split-brain scenarios, where both nodes make changes independently, it is very unlikely that you would have to be concerned about losing information found on server 1 only. 2-node cluster are not recommended, see e.g. documentation page Primary Site Fault Tolerance.

In general this looks like something that a case should be opened for with PAM Support to investigate the cause of the problem.

MARUBUN SUPPORT's profile image
MARUBUN SUPPORT


Thank you for your response.


The end user encountered a Spirit Brain issue during cluster rebuild, and PAM Server 1 remains in a warning state (yellow triangle) at this time.
The end user is concerned about PAM Server 1's storage capacity, particularly the / partition.
Do you know if DE648195 may be involved in this issue?

Is resetting (rebooting) the cluster still the best course of action?


We will also inform this end user that a two-cluster configuration is not recommended.
Regarding support, since the end user is using the EOS version, escalation is difficult.

Ralf Prigl's profile image
Broadcom Employee Ralf Prigl

I assume you found a reference to DE648195 in the release notes for 4.2.4. That would be a concern in environments with heavy A2A usage only. For a customer running an EOS release the only recommendation we can give is to upgrade to a supported release.