Upgrade

Cautions During Upgrade

Behavioral Changes

To see the behavioral changes from 2008 R4.1, please see Behavioral Changes in the release notes.

Saving the Existing Configuration File

  • Save the configuration files in the $CUBRID/conf directory (cubrid.conf, cubrid_broker.conf and cm.conf) and the DB location file (databases.txt) in the $CUBRID_DATABASES directory.

Checking New Reserved Words

  • You can check whether reserved words are being used or not by applying the CUBRID 2008 R4.4 reserved word detection script, check_reserved.sql, which is distributed through the CUBRID installation package or http://ftp.cubrid.org/CUBRID_Engine/8.4.4/Linux/. If the reserved words are being used as identifiers, the identifiers must be modified. See Identifier.

DB migration

  • Since the DB volume of CUBRID 2008 R4.0 or earlier version is not compatible with the DB volume of R4.4, it should be migrated with cubrid unloaddb/loaddb utility.

Note

In 2008 R4.0 or before, TIMESTAMP '1970-01-01 00:00:00'(GMT) is the minimum value of TIMESTAMP, but in 2008 4.1 or later, it is recognized as zerodate and TIMESTAMP '1970-01-01 00:00:01'(GMT) is the minimum value of TIMESTAMP.

  • GLO classes are not supported from 2008 R3.1. Therefore, if you use GLO classes, you must modify applications and schema in order to use BLOB or CLOB types. If this modification is not easy, it is not recommended to perform the migration.

Reconfiguring Environments for Replication or HA

  • From 2008 R4.0, the replication feature is no longer supported; for this reason, it is recommended to reconfigure the DB migration and HA environment for systems in which previous replication versions are used. In addition, for systems that use Linux Heartbeat-based HA feature, which is provided in CUBRID 2008 R2.0 and 2008 R2.1, you must reconfigure to DB migration and the CUBRID Heartbeat-based HA environment for better operational stability(see Database Migration Procedures under HA Environment).
  • To reconfigure the HA environment configuration, see CUBRID HA in the manual.

Java Stored Function/Procedure

Upgrading From CUBRID 2008 R4.1, R4.3 To R4.4

Users who are using versions CUBRID 2008 R4.1, R4.3 should install 4.4 in the same directory and modify parameter values in the existing environment configuration file.

DB migration

Since the DB volume of CUBRID 2008 R4.1 or R4.3 is compatible with the DB volume of R4.4, you can use R4.4 without DB migration.

Parameter configuration

cubrid.conf

  • The value of sort_buffer_size should be configured as 2G or less since the maximum value of sort_buffer_size is 2G.

  • In the following parameters, the old parameters will be deprecated and the new parameters are recommended to use. the value in the parenthesis is the unit of the value when the unit is omitted, and the new parameters can specify the unit after the value. For details, see each parameter's explanation in System Parameters

    Old parameters(unit) New parameters(unit)
    lock_timeout_in_secs(sec) lock_timeout(msec)
    checkpoint_every_npages(page_count) checkpoint_every_size(byte)
    checkpoint_interval_in_mins(min) checkpoint_interval(msec)
    max_flush_pages_per_second(page_count) max_flush_size_per_second(byte)
    sync_on_nflush(page_count) sync_on_flush_size(byte)
    sql_trace_slow_msecs(msec) sql_trace_slow(msecs)

cubrid_broker.conf

  • In KEEP_CONNECTION parameter, OFF value should be changed as ON or AUTO since OFF setting value is no longer used.
  • SELECT_AUTO_COMMIT should be deleted since this parameter is no longer used.
  • The value of APPL_SERVER_MAX_SIZE_HARD_LIMIT should be 2,097,151 or less since the maximum value of APPL_SERVER_MAX_SIZE_HARD_LIMIT is 2,097,151.

cubrid_ha.conf

  • Users who have configured the ha_apply_max_mem_size parameter value more than 500 must the value to 500 or less.

Upgrading From CUBRID 2008 R4.0 or Earlier Versions To R4.4

Users who are using versions CUBRID 2008 R4.0 or earlier should install R4.4 in the different directory and modify parameter values in the existing environment configuration file.

DB migration

The following table shows how to perform the migration using the reserved word detection script, check_reserved.sql, which is separately distributed from http://ftp.cubrid.org and the cubrid unloaddb/loaddb utilities. See Unloading and Loading Database)

Step Linux Environment Windows Environment
Step C1: Stop CUBRID Service % cubrid service stop Stop CUBRID Service Tray.
Step C2: Execute the reserved
words detection script

Execute the following command in the directory where the reserved word detection script is located.

Execute migration or identifier modification by checking the detection result (For the allowable identifier).

% csql -S -u dba -i check_reserved.sql testdb
Step C3: Unload the earlier
version of the DB

Store the databases.txt file and the configuration files under the conf directory of the earlier version in a separate directory (C3a).

Execute the cubrid unloaddb utility and store the file generated at this point in a separate directory(C3b).

% cubrid unloaddb -S testdb

Delete the existing database (C3c).

% cubrid deletedb testdb
  Uninstall the earlier version of CUBRID.
Step C4: Install new version See Installing and Running CUBRID
Step C5: Database creation and
data loading

Go to the directory where you want to create a database, and create one. (C5a)

% cd $CUBRID/databases/testdb

% cubrid createdb testdb

Execute the cubrid loaddb utility with the stored files in (C3b). (C5b)

% cubrid loaddb -s testdb_schema -d testdb_objects -i testdb_indexes testdb
Step C6: Back up the new version
of the DB
% cubrid backupdb -S testdb
Step C7: Configure the CUBRID
environment and start the CUBRID Service

Modify the configuration file. At this point, partially modify the configuration files from the earlier version stored in step (C3a) to fit the new version(For system parameter settings, see the cautions).

(For configuring system parameter, see Parameter configuration and System Parameters)

% cubrid service start

% cubrid server start testdb

Start the service by selecting CUBRID Service Tray > [Service Start].

Start the database server from the command prompt.

% cubrid server start testdb

Parameter configuration

cubrid.conf

  • The value of sort_buffer_size should be configured as 2G or less since the maximum value of sort_buffer_size is 2G.

  • Because the default value of thread_stacksize has been changed from 100K to 1M, it is recommended that users who have not configured this value check memory usage of CUBRID-associative processes.

  • Because the minimum value of data_buffer_size has been changed from 64K to 16M, users who have configured this value less than 16M must change the value equal to or greater than 16M.

  • In the following parameters, the old parameters will be deprecated and the new parameters are recommended to use. the value in the parenthesis is the unit of the value when the unit is omitted, and the new parameters can specify the unit after the value. For details, see each parameter's explanation in System Parameters.

    Old parameters(unit) New parameters(unit)
    lock_timeout_in_secs(sec) lock_timeout(msec)
    checkpoint_every_npages(page_count) checkpoint_every_size(byte)
    checkpoint_interval_in_mins(min) checkpoint_interval(msec)
    max_flush_pages_per_second(page_count) max_flush_size_per_second(byte)
    sync_on_nflush(page_count) sync_on_flush_size(byte)

cubrid_broker.conf

  • In KEEP_CONNECTION parameter, OFF value should be changed as ON or AUTO since OFF setting value is no longer used.
  • SELECT_AUTO_COMMIT should be deleted since this parameter is no longer used.
  • The value of APPL_SERVER_MAX_SIZE_HARD_LIMIT should be 2,097,151 or less since the maximum value of APPL_SERVER_MAX_SIZE_HARD_LIMIT is 2,097,151.
  • The minimum value of APPL_SERVER_MAX_SIZE_HARD_LIMIT is 1024M. It is recommended that users who configure APPL_SERVER_MAX_SIZE configure this value less than the value of APPL_SERVER_MAX_SIZE_HARD_LIMIT.
  • Because the default value of CCI_DEFAULT_AUTOCOMMIT has been changed to ON, users who have not configured this value should change it to OFF if they want to keep auto commit mode.

cubrid_ha.conf

  • Users who have configured the ha_apply_max_mem_size parameter value more than 500 must the value to 500 or less.

Database Migration Procedures under HA Environment

HA migration from CUBRID 2008 R2.2 or higher to R4.4

In the scenario described below, the current service is stopped to perform an upgrade in an environment in which a broker, a master DB and a slave DB are operating on different servers.

Step Description
Steps H1~H6: Perform steps C1-C6 on the master node. Run the CUBRID upgrade and database migration in the master node, and back up the new version's database.
Step H7: Install new version in the slave node

Delete the previous version of the database from the slave node and install a new version.

For more information, see Installing and Running CUBRID.

Step H8: Restore the backup copy of the master node
in the slave node

Restore the new database backup copy (testdb_bk*) of the master node, which is created in step H6 , to the slave node.

% scp user1@master:$CUBRID/databases/databases.txt $CUBRID/databases/.

% cd ~/DB/testdb

% scp user1@master:~/DB/testdb/testdb_bk0v000 .

% scp user1@master:~/DB/testdb/testdb_bkvinf .

% cubrid restoredb testdb

Step H9: Reconfigure HA environment and start
HA mode
In the master node and the slave node, set the CUBRID environment configuration file (cubrid.conf) and the HA environment configuration file(cubrid_ha.conf) See Creating Databases and Configuring Servers.
Step H10: Install new version in the broker server,
and start the broker

For more information about installation, see Installing and Running CUBRID.

Start the broker in the Broker server. See Configuring and Starting Broker, and Verifying the Broker Status.

% cubrid broker start

HA Migration from CUBRID 2008 R2.0/R2.1 to R4.4

If you are using the HA feature of CUBRID 2008 R2.0 or 2008 R2.1, you must upgrade the server version, migrate the database, set up a new HA environment, and then change the Linux Heartbeat auto start setting used in 2008 R2.0 or 2008 R2.1. If the Linux Heartbeat package is not needed, delete it.

Perform steps H1-H10 above, then perform step H11 below:

Step Description
Step H11: Change the previous Linux heartbeat
auto start settings

Perform the following task in the master and slave nodes from a root account.

[root@master ~]# chkconfig --del heartbeat // Performing the same job in the slave node