At times you may need an easy way to remove test data so that you have a clean system. The easiest way to clean up the system when using Global Mailbox is to remove all message data from the Cassandra tables.  This involves using the “truncate” CQLSH command to remove all contents of certain tables. Additionally you must delete all payload data from the disk.

Warnings: 

• By default Cassandra makes a backup of all truncated data. This allows you to re-import the data if you accidentally removed data you didn’t intend to. These backups take up space on disk.  You can disable this backup function by setting auto_snapshot to false in the cassandra.yaml file on each Cassandra node.  A rolling restart of the Cassandra nodes is required if you change this value.  Review the Cassandra documentation to determine if you want to set this flag or manually clean up snapshots (backups) on each node.
• This these instructions apply to Global Mailbox 6.1.x.
• Backup of all deleted data is recommended

Before cleaning up data, it is best to stop all B2Bi/SFG/GM processes to ensure that new data is not being created while cleaning up the messages.

Follow these steps to clean up the message data.

1. Ensure all Cassandra nodes are running. Truncation will fail if some nodes are down.
   
   
2. Launch CQLSH
   
   <Global Mailbox Dir>/apache-cassandra/bin/cqlsh <Cassandra host> <Cassandra port>
   
   If you don’t know which port to use, see native_transport_port in the cassandra.yaml configuration file
   
   
3. Remove data from the messages tables by invoking the following:
   
   use mailbox;
truncate as2_msg_id_correlation_out;
truncate as2_msgmdncorrelation;
truncate expired_message_purge_queue;
truncate expired_message_purge_queue_ptr;
truncate expiring_message_queue;
truncate expiring_message_queue_ptr;
truncate expiring_message_registration;
truncate message_extractions;
truncate message_purge_queue;
truncate message_purge_queue_ptr;
truncate messages;
truncate messages_by_id;
truncate messages_by_name;
truncate messages_by_payload;
truncate payload_purge_queue;
truncate payload_purge_queue_ptr;
   
   
4. Remove data from the events tables by invoking the following:
   
   use event;
truncate events;
truncate events_by_mbx_app_rule_msg;
truncate events_by_message;
truncate events_message_created_storage_id;
truncate events_processing_status;
truncate events_processing_status_ptr;
truncate events_purge_queue;
truncate events_purge_queue_ptr;
   
   
5. Remove data from the replication tables by invoking the following:
   
   use replication;
truncate payload_register;
truncate payloads_by_bucket;
truncate payloads_by_dc;
truncate replication_queue;
truncate replication_queue_ptr;
truncate segments;
   
   
6. Take note of the list of datacenter_ids:
   
   select datacenter_name, datacenter_id from gatekeeper.datacenters;
   
   
7. For each data center ID from the previous step, invoke the following to remove additional data about replicating payloads:
   
   use replication;
truncate dc_<dc id replacing – with _>;
   
   For example, if a data center has the ID f4541adc-950d-4d08-956c-f8c3a801b085, the truncate command is  truncate dc_f4541adc_950d_4d08_956c_f8c3a801b085;
   
   
8. Exit CQLSH:
   
   quit;
   
   
9. In each data center, remove the payloads from the local shared disk:
   
   rm -rf <shared disk>/global_mbx_var00/expiration/*
   
   Ensure that you DO NOT delete the config folder for the storage bucket.
   Ensure that you DO NOT delete the expiration folder itself.  You will get errors if it is missing.
   If you have additional storage buckets and variants, remove the data from those as well.
   
   
10. Restart all B2Bi/SFG/GM servers.

All messages and related objects are cleared from the system and no messages will appear in any mailboxes.