Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[EOL/EOE] How to determine if the High Availability database synchronization is complete in NSM 2007.2 or higher

0

0

Article ID: KB10366 KB Last Updated: 18 Oct 2020Version: 7.0
Summary:
Note: A product listed in this article has either reached hardware End of Life (EOL) OR software End of Engineering (EOE).  Refer to End of Life Products & Milestones for the EOL, EOE, and End of Support (EOS) dates.
This article provides information on how to determine if the High Availability database synchronization is complete in NSM 2007.2 or later.
Symptoms:
  • Prior to NSM 2007.2, NSM used hourly rsync to synchronize High Availability databases. NSM 2007.2 or later uses an internal database synchronization, which is more robust and efficient.

  • Which messages and commands show the initial synchronization was finished and successful?
Solution:

To check HA synchronization, run the following command: 

/usr/netscreen/HaSvr/utils/haStatus

The output will display the HA process as ON and the HA status as in-sync:
              
      [root@nsm-vm-xdb]# /usr/netscreen/HaSvr/utils/haStatus

      =======================================================
      H/A process status
      =======================================================

      Retrieving status...
      highAvail (pid 26654)..............................ON
      highAvailSvr (pid 27828)...........................ON

      =======================================================
      State of the local and peer H/A server
      =======================================================

      Local Server:
      172.22.123.12 running network-up db-repl:in-sync

      Peer Server:
      172.22.123.13 standby network-up db-repl:in-sync



For more information, view the guiDaemon.0 log on the secondary server:

 view /var/netscreen/GuiSvr/errorLog/guiDaemon.0


In the log, these messages will be present, if the initial sync was successful:

[timestamp] [Notice] [session details] get BDB event DB_EVENT_REP_CLIENT
[timestamp] [Notice] [session details] get BDB event DB_EVENT_REP_NEWMASTER
[timestamp] [Notice] [session details] get BDB event DB_EVENT_REP_STARTUPDONE
[timestamp] [Notice] [session details] haDbClearDirtyFlag


The haDbClearDirtyFlag reference is displayed by checking the DB state via the above haStatus command. A DB, which has its DirtyFlag cleared, is in-sync.

Another way to make sure that the synchronization is started and is progressing is to check the size of the /usr/netscreen/GuiSvr/var/xdb/data folder on the secondary NSM server. You can put a watch on the size of the data directory to make sure that it is increasing and it reaches the same size as that of the data directory on the primary NSM server. The Watch command is used to run any arbitary command at regular intervals and display the output of the same on the terminal. By default, watch will run the specified command every two seconds.

           [root@nsm-vm-primary]# du -hs /usr/netscreen/GuiSvr/var/xdb/data
     2.3G   /usr/netscreen/GuiSvr/var/xdb/data
    
     [root@nsm-vm-secondary]# watch du -hs /usr/netscreen/GuiSvr/var/xdb/data
    
     Every 2.0s: du -hs /usr/netscreen/GuiSvr/var/xdb/data
    
     58M   /usr/netscreen/GuiSvr/var/xdb/data
    
The size of the data directory on the secondary NSM server will keep on increasing and will reach 2.3G. Once it reaches 2.3G, then the initial     synchronization will be finished and we can cross verify the status of the database replication from the haStatus command mentioned above.

P.S. Please make sure that the size of the /usr/netscreen/GuiSvr/var/xdb/data directory is checked and not the /usr/netscreen/GuiSvr/var/xdb/ directory. The data directory is the one that gets replicated between the two servers. If you run a watch on the size of the xdb directory, then you might see a difference in the size of the xdb directories on both the servers because the xdb directory on the primary NSM server might contain extra files like the "xdb<PID>.tar.gz" which are normally created after an export / import of the NSM database is performed.
   

 

Modification History:
2020-10-18: Tagged article for EOL/EOE.
 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search