We would like to understand the actual purpose of pr_sys_statusnodes table, from following spect.
Assume we have 6 nodes a1,a2,b1,b2,c1,c2, where a1,a2 are background nodes, but b1/b2 and c1/c2 are 2 user clustered nodes.
a. During what time, entries for this table are populated with required details of nodes (App server instances). How frequently they are updated and by whom.
b. We have seen pyClusterAddress of this table is populated with EMBEDDED for batch node (a1/a2) specific rows, where as other user cluster nodes are populated with IP addresses. Could some one know/explain in which situation EMBEDDED will be populated.
c. Does this table has any impact in processing of any Pega agents? I hope not.
Could you please help us in understanding more about this!!
Purpose of pr_sys_statusnodes : Contains one row for each participating node in the system, corresponding to instances of the System-Status-Nodes class.
a. During what time, entries for this table are populated with required details of nodes (App server instances). How frequently they are updated and by whom : I guess for the first time when server is started and when we restart server by truncating this tables, data gets populated.
c. Does this table has any impact in processing of any Pega agents? : I am not sure of agents , however it impact pega search if it does not contain the correct util/search nodes.
This table holds the node(s) information(System-Status-Nodes instances) and each record represents a node(JVM) in order to form a cluster.
Hazelcast cluster initialization uses the records as member IP's and Search functionality uses the records to differentiate Index nodes using the pyIndexDirectory column value.
Also apart from your regular JVM's, if you run any CLI actions using prpcUtils script, Pega initialization happens in embedded mode and there should be a record for that with system name as "prpc" despite having a different system name. However, the embedded status is unrelated to CLI actions and should be present for different reasons.
Hazelcast is checking for pyClusterAddress for a valid IP and if it finds empty, null or EMBEDDED values it prints the below INFO message in startup for a1/a2.
Skipping " + otherNodeId + " since it's a non-conforming cluster address: " + clusterAddress);
If this is the case, verify if a1/a2 is a part of your hazelcast cluster and also check if identification//cluster/protocol is set to any value other than "hazelcast". I would recommend an SR if you have more queries in these lines.
a. In addition to startup & shutdown, the PYLASTPULSEDATETIME column gets updated with the last pulse run time on the specific node every 10 mins.