Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.3.1 |  CUBRID 8.4.0 |  CUBRID 8.4.1 |  CUBRID 8.4.3 |  CUBRID 9.0.0 | 

Migrating Database

To use a new version of CUBRID database, you may need to migrate an existing data to a new one. For this purpose, you can use the "Export to an ASCII text file" and "Import from an ASCII text file" features provided by CUBRID. The following section explains migration steps using the cubrid unloaddb and cubrid loaddb utilities.

Recommended Scenario and Procedures

The following steps describes migration scenario that can be applied while the existing version of CUBRID is running. For database migration, you should use the cubrid unloaddb and cubrid loaddb utilities. For details, see Unloading Database and Loading Database.

  1. Stop the existing CUBRID service

    Execute cubrid service stop to stop all service processes running on the existing CUBRID and then check whether all CUBRID-related processes have been successfully stopped.

    To verify whether all CUBRID-related processes have been successfully stopped, execute ps -ef|grep cub_ in Linux. If there is no process starting with cub_, all CUBRID-related processes have been successfully stopped. In Windows, press the <Ctrl+Alt+Delete> key and select [Start Task Manager]. If there is no process starting with cub_ in the [Processes] tab, all CUBRID-related processes have been successfully stopped. In Linux, when the related processes remain even after the CUBRID service has been terminated, use kill command to forcibly terminate them, and use ipcs -m command to check and release the memory shard by CUBRID broker. To forcibly terminate related processes in Windows, go to the [Processes] tab of Task Manager, right-click the image name, and then select [End Process].

  2. Back up the existing database

    Perform backup of the existing version of the database by using the cubrid backupdb utility. The purpose of this step is to safeguard against failures that might occur during the database unload/load operations. For details on the database backup, see Database Backup.

  3. Unload the existing database

    Unload the database created for the existing version of CUBRID by using the cubrid unloaddb utility. For details on unloading a database, see Unloading Database.

  4. Store the existing CUBRID configuration files

    Store the configurations files such as cubrid.conf, cubrid_broker.conf and cm.conf in the CUBRID/conf directory. The purpose of this step is to conveniently apply parameter values for the existing CUBRID database environment to the new one.

  5. Install a new version of CUBRID

    Once backing up and unloading of the data created by the existing version of CUBRID have been completed, delete the existing version of CUBRID and its databases and then install the new version of CUBRID. For details on installing CUBRID, see Installing and Running on Linux in "Getting Started."

  6. Configure the new CUBRID environment

    Configure the new version of CUBRID by referring to configuration files of the existing database stored in the step 3, "Store the existing CUBRID configuration files." For details on configuring new environment, see Installing and Running on Windows in "Getting Started."

  7. Load the new database

    Create a database by using the cubrid createdb utility and then load the data which had previously been unloaded into the new database by using the cubrid loaddb utility. For details on creating a database, see Creating Database in "Administrator's Guide." For details on loading a database, see Loading Database.

  8. Back up the new database

    Once the data has been successfully loaded into the new database, back up the database created for the new version of CUBRID by using the cubrid backupdb utility. The reason for this step is because you cannot restore the data backed up in the existing version of CUBRID when using the new version. For details on backing up the database, see Database Backup.

Caution
Even if the version is identical, the 32-bit database volume and the 64-bit database volume are not compatible for backup and recovery. Therefore, it is not recommended to recover a 32-bit database backup on the 64-bit CUBRID or vice versa.