CSSCurrent en:Database Migration
General
In this update the previously used orientDB database is replaced by an H2 database. For the continued retrieval of all sent transfers they and all settings are migrated from the old database to the new one. The migration takes place automatically during the post update process. Usually no special actions are necessary for the administrators (see below).
What advantages do I have?
Due to the usage of another database engine the new database is more reliable, significantly faster and more firmly established than the OrientDB database. It offers a lower memory and processing power requirements. By using database specific techniques database integrity can be guaranteed even better. Additionally, database specific processing steps were removed, so the duration of various processes is reduced even more. The new database offers a higher number of parallel access and is even more suitable for sending many parallel transfers.
What changes does the database update have on configuration and installation?
Changed configuration
- The pool size configuration for high server load changes. Please consult the article Database Configuration.
- OrientDB specific parameters were removed from the Advanced Cryptshare Configuration.
Changed directory structure
All files needed for usage of the orientDB database were located in the orientDB subdirectory in the Cryptshare installation directory. During the database migration the new database is written to the subdirectory db. Please note that when you used a link for the orientDB directory leading to another hard disk, you should set-up a new link for the db directory prior to the migration.
How much time is necessary for migrating the database?
The migration heavily depends on the amount of previously sent transfers. The operation may take from several minutes to up to an hour.
Is all data migrated to the new database?
Transfers which expired more than 12 months ago and address book entries (when entering recipients in the Web App) which were used at last over 12 months ago are not migrated to the new database. As a result statistics data older than 12 months are not available any more after the migration. The Transfer Log only shows transfers which are not expired yet or were sent in the last 12 months. (When restoring the previous version, you are able to export the Transfer Log as a CSV file prior the migration, see Log View).
What issues may occur?
A migration finishes with one of three states:
- Successful
- Migration with warnings
- Failed migration
Successful Migration
What options do I have?
- The post update can be finished without the need to check settings and policy rules for their correctness. After restarting the server Cryptshare is immediately usable with the new database.
- It is also possible to restore the previous Cryptshare version.
What are the consequences?
As soon as you finish the post update and restart the server, you are immediately using the new database. As mentioned above all transfers expired over 12 months ago and thus were not retrievable anymore were deleted and are not covered by the statistics page and the transfer log.
Migration with warnings
What options do I have?
Information in the migration log
Generally, in this case we recommend to check the log file 'Cryptshare Database Migration'.
When users have questions at a later time regarding the accessability of transfers, administrators are able to lookup in the migration log if a transfer could not be migrated due to an error.
After you have checked the log file, you are free to continue the update process and to start using the Cryptshare server with the values set. If you are unsure or do not want to take the risk accompanied by the changes, you are able to restore the previous Cryptshare version.
Settings and policy rules could not be migrated
In rare cases it is possible that settings and policy rules could not be migrated completely. Please check all affected settings in the administration interface after restarting the server. The following examples show an excerpt from the log which shows such errors: `WARN 2020-01-01 09:00:00 BaseEntityHandler - Required property 'Verification code validity` `' for entity 'VerificationSettings' missing! Setting default to '15' ` This entry shows that the setting 'Verification code validity' could not be migrated. You are able to correct this value manually in the administration interface in the menu "System-Settings" → "Verification". `WARN 2020-01-01 09:00:00 BaseEntityHandler - Property 'Sender Address' for entity 'PolicyRule' is too long (max length '320'). Cut off value!` This entry shows that the setting 'Sender Address' has a too long value and is cut off. You are able to correct this value manually in the administration interface in the menu "System-Settings" → "Policy Settings". `WARN 2020-01-01 09:00:00 BaseEntityHandler - Property 'SMTP Password' for entity 'MailSettings' is too long (max length '4000'). Clear value!` This entry shows that the setting 'SMTP Password' has a too long value and is cleared. You are able to correct this value manually in the administration interface in the menu "System-Settings" → "Mail Server Settings".
Loss of transfer data
In rare cases it is possible that transfer related data or QUICK connections were not be migrated, since they were corrupt already. Affected transfers cannot be retrieved and are not covered by the statistics. Corrupt QUICK connections have to be re-established. The log file will show a summary how many transfers and QUICK connections were migrated successfully:
Example: Amount of successfully migrated transfers INFO 2020-01-01 09:00:00 TransferEntityHandler - Successfully migrated 900 of 1000 'Transfer'. Optimized database and skipped 100 outdated entries.
In this example 900 of 1000 transfers were migrated successfully. The remaining 100 transfers expired more than 12 months ago and were already not retrievable. As a result these transfers were not migrated to the new database.
What are the consequences?
- Single settings and policy rules may have been set to their defaults. Please use the log file for checking whether the settings meet your requirements.
- Transfers which could not be migrated are not retrievable anymore. A list with corresponding tracking ids can be found in the log file.
Failed Migration
What options do I have?
- Check if your system has enough free RAM. For the database migration at least 2 GB free RAM is necessary.
- Furthermore, the system should have enough free disk space. Please check if the Cryptshare installation directory has at least as much space as the size of the orientDB directory. For regular Cryptshare operations at least 2 GB free disk space should be available.
- When you are using a Linux system, the system user csuser must have write and read access to the Cryptshare installation directory and the sub directory db.
- You can start a new migration attempt after the problems mentioned above have been solved.
What are the consequences?
- When the migration fails although RAM and available disk space are sufficient, please contact the Cryptshare Support. In order to continue using the Cryptshare Server, perform a rollback to the previous Cryptshare version.
