• In case flush was successful :

  This is the status normally expected. There is no data loss, because flush has been executed. Therefore, there is no need to take further action.
• In case flush failed :

  When the planned stoppage is made, flush would be normally executed and data integrity at the time of stoppage would be secured. However, flush may sometimes fail at the time of stoppage.

  Data that was on the memory would be lost, because flush was not successfully executed.

• In case flush has been executed :

  Flush may have been executed before the abnormal stoppage.

  Since flush has been executed, there is no data loss. Therefore, there is no need to take further action.
• In case flush has not been executed or has failed :

  Flush is normally not executed before the abnormal stoppage. Therefore, it will fail even if it is executed.

  Data that was on the memory would be lost, because flush was not successfully executed.

Note

Regardless of whether it is a planned stoppage or abnormal stoppage, there is a risk of data loss because of the flush failure.

• In case it is built with a single node :

  IMBox will not be available until Cassandra is restored.

  Note

  In the case of single node operation, data loss will not occur, because read/write operation cannot be executed when the network is disconnected.
• In case it is built as a cluster :

  Status would change depending on the number of nodes disconnected from the network.
  • In case the number of available units allow service to continue :

    For example, if 1 unit is disconnected while [3 nodes (replication factor is 3)] are in operation, the service can continue normally with the other 2 units.

    When the disconnected node is reconnected to the network, missing data is replicated (copied) and the normal operation status is resumed.
  • In case the number of available units do not allow service to continue :

    IMBox becomes unavailable until Cassandra is restored.

    For example, if 2 units are disconnected while [there are 3 nodes and replication factor is 3], the service cannot be continued.

    Since the service becomes unavailable and read/write operations cannot be performed, there would be no data loss.

Note

This countermeasure only reduces the possibility or amount of data loss.

Please see this for Flush.

Note

Frequency of flush execution should be coordinated with the conditions required by the operations design.

Following items would need to be assessed.

• Maximum amount of time in which data loss situation might be allowed
• Impact on service response time and server load by the increased I/O load by the periodic flush execution

• In case number of nodes are 2 :

  In case there are 2 nodes in the cluster, service continuation (data read and write) would not be possible if one of the nodes is stopped.

  If the service cannot be continued, data loss would not occur, because data write cannot be made.
• In case number of nodes are 3 (or more) :

  In case there are 3 nodes in the cluster (and the replication factor is 3), the service can continue even if 1 node is stopped.

  When the stopped node is recovered, missing data for the stopped node is replicated (copied), and the normal operation status would be resumed when the replication is completed.
  If 2 nodes out of 3 nodes are stopped at the same time, the service cannot be continued. Therefore, recovery process is necessary when 1 node is stopped.

  However, since data write cannot be made when the service cannot be continued, data loss would not occur.

Note

It can be restored by executing the dedicated job (job net).

For the details, please refer to [IMBox Specifications - Job Scheduler].

Note

Since the attachment files are saved on the file system (PublicStorage), they can be restored by the System Administrator.

For the saving location of attachment files, please refer to [IMBox Specifications - Action -File].