Table migration
Table data is often the most important information that can be copied between Deephaven deployments. Migrated table data cannot be viewed until appropriate schemas are restored on the target host. Environment-specific data files (tables) are stored under /db/Systems, /db/Users, /db/Intraday/<Namespace>, and /db/IntradayUser.
Migrating historical and user data
Typically, /db/Users and /db/Systems are shared across nodes using NFS or similar shared storage. Attaching (or reattaching) such shared storage to the new servers will make historical and user data available to the new cluster.
If NFS mounting is not possible or practical (across WAN, for example), then the data must be copied to the new site using a utility such as tar, scp, rsync, etc.
Migrating intraday data
/db/Intraday has subdirectories for each namespace. The DbInternal namespace is reserved for Deephaven internal operations and should not be copied between installs. The one exception to this "rule" is the DbInternal.WorkspaceData table, which may be migrated to a new deployment. The DbInternal.WorkspaceData table defines user workspace data, which may be valuable across platforms, while the rest of the DbInternal tables show platform-specific performance metrics, logs, and stats.
Other namespace subdirectories under /db/Intraday may be copied to the new ingestion server. Before copying intraday data between clusters, it is critical that the DataImportServer / DIS and Local Table Data Server / LTDS are stopped on the source host and the target host. Once the data is successfully coped, these services may be started.
Similarly, /db/IntradayUser may be copied to the new cluster when the DIS and LTDSservices are stopped on both environments.
Warning
Ensure file and directory ownership and permissions are preserved when copying data directories between servers. Note that installation-specific information under /db/TempFiles must not be copied between installations.