Aggregator CLI Commands
This section list Aggregator CLI commands.
aggregator backup keys file
Use this command to back up the shared secret keys file to the specified location.
Syntax
aggregator backup keys file <user@host:/path/filename>
Parameters
user@host:/path/filename For the file transfer operation, specifies a user, host, and full path name for the backup keys file. The user you specify must have the authority to write to the specified directory.
aggregator debug
Starts or stops writing debugging information relating to aggregation activities. Use these commands only when directed to do so by Guardium® Support, and be sure to issue the stop command after you have gathered enough information.
Syntax
aggregator debug <start | stop>
aggregator list failed imports
When an import operation fails because of a shared secret mismatch, the offending file is moved from the /var/importdir directory to the /var/dump directory, and it is renamed using the original file name plus the suffix .decrypt_failed. Use this command to list all such files
Syntax
aggregator list failed imports
aggregator recover failed import
Use this command to move and rename failed import files, prior to re-attempting an import or restore operation. Failed import files are stored in the /var/dump directory, with the suffix .decrypt_failed. Before re-attempting an import or restore operation, those files must be renamed (by removing the .decrypt_failed suffix) and moved to the /var/importdir directory.
Syntax
aggregator recover failed import <all | filename>
Parameters
Use the all option to move all files from the /var/dump directory ending with the suffix .decrypt_failed, or use the filename option to identify a single file to be moved.
aggregator restore keys file
Use this command to restore the shared secret keys file from the specified location.
Syntax
aggregator restore keys file <user@host:/path/filename>
Parameters
user@host:/path/filename For the file transfer operation, specifies a user, host, and full path name for the backup keys file.
store aggregator drop_ad_hoc_audit_db
Audit Process reports on Aggregator – creates ad-hoc databases for each of its tasks that will include only the relevant days for that task. These ad-hoc databases can be kept for 14 days (for analysis) or deleted immediately after use. The CLI command defines the ad-hoc databases purging policy. Choices are 0 or 1(0 - keep for 14-days or 1 - delete after use).
Syntax
store aggregator drop_ad_hoc_audit_db [1|0]
Drop ad-hoc merge databases? 0
show aggregator drop_ad_hoc_audit_db
store aggregator orphan_cleanup_flag
Use this CLI command to regularly run static orphans cleanup on an aggregator.
Use this CLI command to clean orphans on aggregators that will be scheduled to run on data older then 3 days and will run at the end of a purge.
This process will be started by the user with this CLI command, so in case of large database, the user will be aware of the time length of the process.
It will cover the whole data on the aggregator, but will run it all on a separate temporary database.
show aggregator orphan_cleanup_flag Displays small, large or analyze.
store aggregator orphan_cleanup_flag
store aggregator orphan_cleanup_flag <flag>, where flag is one of the words < small large analyze >
These commands are applicable on aggregator only.
If set to one of small, large or analyze - orphans cleanup script is invoked after each run of merge process.
The orphans cleanup on an aggregator does not remove orphan records of the last 3 days - it does remove all orphans older then 3 days.
If small is specified, the process does not interfere with audit processes that can start after the merge is completed.
If large is specified, the process would run faster where there is a large number of orphans but it's run might interfere with audit processes - if large is specified, audit processes will not start until orphans cleanup is complete.
If analyze is specified, the process first evaluates the number of orphans and uses the large tactics if there are more than 20% orphans - if analyze is specified, audit processes will not start until orphans cleanup is complete.
Syntax
store aggregator orphan_cleanup_flag [ small | large | analyze]
Show command
show aggregator orphan_cleanup_flag
store archive_static_table
Use this CLI command to turn off/ turn on the archive static table
USAGE: store archive_static_table <state>,
where state is on/off.
Show command
show archive_static_table
store next_export_static
- static tables - grow slowly over time, data in these tables is not time dependent (GDM_OBJECT, GDM_FIELD, GDM_SENTENCE, GDM_CONSTRUCT, etc.).
- dynamic tables- grow quickly with time, data is time dependent (GDM_CONSTRUCT_INSTANCE, GDM_SESSION, GDM_CONSTRUCT_TEXT etc.).
As stated previously, the data of static tables is not time dependant. The data of dynamic tables that is time dependant is linked to static data. As static tables can grow to be very large, the export/archive process does not archive the full static data every day - it archives the full static data the first time it runs, and then at the first day of each month, on any day besides the first of the month, it only archives static data that changed during that day. For this reason when restoring data of any day, it is also required that the first of the month be restored - this ensures that full static data is present and references are not broken.
Use the CLI command, store next_export_static, to set a flag so that the next export contains the full static data.
Syntax
store next_export_static [ON | OFF]
Show command
show next_export_static
store last_used
Use this CLI command during purging and aggregation.
Syntax
store last_used [size | interval | logging]
Show command
show last_used [size | interval | logging]
LAST_USED SIZE - Integer, Default is 50
LAST_USED INTERVAL - Integer, default is 60 (minutes)
LAST_USED LOGGING - Integer
All Tables - 1
Only GDM_Object - 2
None - 0 (Default)
store aggregator static_data
store aggregator static_data [TIMESTAMP | LAST_USED_FOR_OBJECT_ONLY | LAST_USED ]
When the LAST_USED column is updated by the Sniffer in Static tables, this column can be referenced when purging data from these tables or when archiving and exporting data from these tables.
The value of this column can also be updated when importing data to an aggregator.
- By default, the system behaves like it did in previous versions - the LAST_USED column is not considered in purge, archive and export and is not updated on import, archive and export are done by TIMESTAMP.
- LAST_USED_FOR_OBJECT_ONLY is considered only for GDM_OBJECT table.
- LAST_USED is considered for GDM_CONSTRUCT, GDM_SENTENCE, GDM_OBJECT, GDM_FIELD, GDM_JOIN, GDM_JOIN_OBJECT
Syntax
store aggregator static_data <type>
where <type> is <TIMESTAMP | LAST_USED | LAST_USED_FOR_OBJECT_ONLY>depends on the last_used logging flag.
Use show/store last_used logging commands.
Show command
show aggregator static_data
store archive_table_by_date
Use the CLI command, store archive_table_by_date, only on Aggregators. Use this CLI command to archive all static tables on a daily basis or archive static tables data at the first time of running and every first day of the month. In default, archive data on an aggregator will run with full static tables on a daily basis. If this CLI command is set to ENABLE, static tables will be archived only on the first day of month or the first time archive data is running.
store run_cleanup_orphans_daily
Use this CLI command to clean all the old construct records that are no longer in use. This CLI command is relevant for collectors and aggregators and by default is enabled.
store run_cleanup_orphans_daily
USAGE: store run_cleanup_orphans_daily [on|off]
Show command
show run_cleanup_orphans_daily
store max_number_collector
Set the maximum number of collectors managed by aggregator. Default is 10.
Show command
show max_number_collector
store purge_age_period
Set the period of purge age.
Show command
show purge_age_period