Call us: +1-415-738-4000

Migration and Version Comparison

Upgrading from 3.7 or 4.0

This page outlines the major topics to consider when moving from BigMemory Max version 3.7 or 4.0 to a higher version. Every installation is unique, with many factors that affect migration. This page can be used as a checklist of relevant topics and basic migration tasks.

Summary of Changes

For release notes and additional release-specific information, refer to the Product Information page.

Area of Change Change from 3.7 to 4.0 Change from 4.0 to 4.1
TSA Operation New Automatic Resource ManagementRecovery from Near-Memory-Full ConditionsContinuous Uptime for 4.0 and higher Changes to Automatic Resource Management and Recovery from Near-Memory-Full Conditions for BigMemory Hybrid
TSA Disk Usage Data held in memory only • Fast Restartability BigMemory Hybrid
TSA Configuration Simplified Configuration of tc-config.xml for 4.0 and higher • No more DSO • offheap required offheap configuration change • dataStorage and hybrid elements added • maxDataSize element deprecated
TSA Monitoring Terracotta Management Console (TMC) replaces Dev Console Data Lifecycle support • Hybrid statistics
TSA Security Security Changes for 4.0 and higher
WAN Replication WAN Replication Service
Interoperability BigMemory Hadoop Connector Cross-language Clients
Search Query using BigMemory SQLSupport for NullsPagination
API Refresh AheadEhcacheSizeOfEngine
Tier Configuration MaxEntriesInCache replaces MaxElementsOnDisk MaxElementsInMemory deprecated (use MaxEntriesLocalHeap instead)
Pinning Key-level pinning removed • PinningConfiguration.Store#LOCALHEAP removed
Statistics Statistics Changes for 4.0 and higher

Continuous Uptime for 4.0 and higher

Improvements to provide continuous availability of data include:

  • Support for multiple mirrors in mirror groups, with better utilization of extra mirrors.
  • Flexibility in server startup sequencing. A mirror server can start up first during a cluster restart, and it will wait for the active server.
  • Multi-stripe backup capability.
  • Optimizations to bulk loading.
  • Performance improvements for data access on rejoin.
  • No more Oracle Berkeley DB, enabling in-memory data to be ready for use much more quickly after any planned or unplanned restart.

Simplified Configuration of tc-config.xml for 4.0 and higher

The tc-config.xml has extensive changes from version 3.7:

  • The <mirror-group> element can now wrap <server> configuration blocks, eliminating the need to repeat the setup of <server> information.
  • <dso-port> is renamed to <tsa-port>, and <l2-group-port> is renamed to <tsa-group-port>.
  • <client-reconnect-window>, <garbage-collection> (DGC), and <restartable> settings are now global for all servers.
  • The <data> element specifies where to store data files used for the Fast Restartability feature.
  • The <clients> section now has one setting, <logs>.
  • <security> is a new configuration block for setting up authorization/authentication and SSL.
  • <dso>, <system>, <statistics>, <persistence>, and <ha> (and, unless otherwise noted, any sub-elements) have been removed.

See the TSA Configuration Reference for a complete listing and definitions of configuration elements.

Security Changes for 4.0 and higher

The following are new in 4.0 and continue in 4.1:

  • HTTP authentication no longer supported.
  • Security is enabled at the Terracotta Management Server (TMS) level, and so the server scripts only need the following when security is enabled:
    • https TMS URL
    • username and password
  • Keychain entries are required for Terracotta clients, servers, and the Terracotta Management Console (TMC). By default, the keychain script that creates Terracotta keychain files uses an obfuscation scheme to protect passwords.
  • Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) support is available for Terracotta servers (see Securing Terracotta Clusters).
  • Custom SecretProvider is available for Terracotta clients (see Setting up LDAP-based Authentication).

For an overview of Security setup, refer to the Security Overview page.

Statistics Changes for 4.0 and higher

Beginning in version 4.0, statistics are no longer explicitly enabled or disabled via the ehcache.xml configuration file. The core counters for statistics are always enabled, but they have no impact on performance.

If you call for a statistic, via the TMC or programmatically, the various components of the statistic (latency, avg, min, max, history) will start being kept. As long as the statistic continues to be sampled within a defined amount of time, that statistic will be kept active.

Note that this is done on a per-statistic basis, so the overhead can vary depending on how many statistics are being sampled.

Overview of the Migration Procedure

  1. Download the BigMemory kit, and verify that you have the correct license keys for the version you are installing.

  2. Prepare the new configuration files. Sample configuration files are located in the BigMemory kit in the config-samples/ directory. You can modify the sample files with specific information for your installation.

  3. (Optional) If you have persistence enabled, you can make a backup of your data.

    • For version 3.7, refer to this Backup section.

    • For version 4.0, refer to this Backup section.

  4. Shut down the server array. A safe shutdown procedure includes the following steps:

    a. Shut down the mirror servers using the stop-tc-server script.

    b. Shut down the clients. A Terracotta client will shut down when you shut down your application.

    c. Shut down the active servers using the stop-tc-server script.

  5. Clear the servers by removing the old version of BigMemory, and by deleting the objectdb data that is saved in the server’s data directory.

  6. Install the new BigMemory kit. You must upgrade all Terracotta clients and servers in the cluster to the same version before restarting the cluster.

  7. Start the servers with their new configuration files.