Confirming Forced Re-indexes for Mandatory Airlock Server Upgrades

Modified on Fri, 24 Nov 2023 at 10:15 AM

Applies to

Airlock Server - (On-premises)


Preface

When upgrading an on-premises Airlock instance from an older server version, there are mandatory versions that may need to be upgraded to first before going directly to the most recent available version. The list of optional and mandatory upgrade versions can be seen in the Upgrade Path of the Airlock Server article to confirm if a target instance needs to upgrade to any mandatory versions before going straight to the latest.


This article aims to provide a process for confirming the completion of the force re-index process that occurs on the mandatory upgrade versions. This process needs to be completed before moving onto the next upgrade version.


At the time of writing, the force re-index process is performed when upgrading to the following mandatory server versions:

  • v2.3.0
  • v3.1.0
  • v4.0.x
  • v4.8.x

Process

When upgrading to any mandatory versions of the Airlock server that performs a forced re-index, the execution history count will need to be checked, this can give an approximate indication on how long this process will take to complete before the next upgrade step can be performed.


While the upgrade process itself can take between 20-30 mins, the re-indexing process can take anywhere between 30mins to a few hours depending on the execution history count.


To get this count, the following command will need to be run on the Airlock server's back end. There are two commands to cover both podman and docker. Docker is used on all CentOS/RHEL versions v8.0 and below, podman is used on CentOS/RHEL v8.1 and above:


podman exec -it airlock_server mongo airlock --eval 'db.exechistories.count()'
or
docker exec -it airlock_server mongo airlock --eval 'db.exechistories.count()'


This will print the number of executions within the database. For an approximate scale, ~10mil entries will take ~1hr to re-index.



If there are upwards of 50mil entries, it is recommended that the Database History Retention feature is used to trim the database, this can also be considered a best practice method regardless of the execution history count. This setting can be found on the Web Console in Settings --> Database --> Database Execution History Retention. This will have a drop-down menu that will allow the selection of a timescale for the Airlock Server to retain Execution History.


It is important to note that this will not remove any of the repository data for files or metadata that is stored within the database, this will only remove execution history that has occurred prior to the timescale set. Once this has been set, there will need to be a 24hr period of waiting for the Airlock server to completely trim the execution history to within the timescale selected.


After the 24hr period has completed, the exechistories count should drop depending on the timescale that was set. This will in-turn reduce the amount of time the re-indexing will take.

 

The mandatory server installer can now be run. After running the installer, a database log can be tailed and allows the progress of the re-indexing process to be monitored.

tail -f /opt/airlock_data/log/mongodb.log

The logs displayed by the above command should look similar to the screenshot below:


Please note, there may be de-duplication occurring as well, in which case it may take a while (up to 30mins, and sometimes longer) for the re-index logs to appear. 


Once the re-indexing has completed the log will have significantly reduced reporting. Once completed, the next step in the upgrade path can be taken.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article