CUBRID Automated Scripts for DB Hosting Service
Table of Contents
1. Overview
Often we receive requests from Hosting companies and other developers to publish some scripts for automated installation and administration of CUBRID in hosting environment. So this article explains how you can automate the installation process, manage the database quota, users, etc.
Below you can download the automation scripts for easy administration of CUBRID database. Besides this article, you can refer to code comments, provided in each script file, when you optimize them for your hosting system. At the moment of writing this article top 3 major hosting service providers in Korea already provide CUBRID DB hosting. As we gather requirements from other hosting company, we will be publishing new materials that you can use for your service.
Downloads
| File name | Size |
| hosting_db_script.zip | 5 KB |
2. Limitation
Before proceeding, let's review the limitations which hosting companies come across when installing CUBRID for their environment.
- User Quota: there is no feature in CUBRID to limit DB quota, CPU usage, Memory usage for each user. However, you can put limitations on your operating system. Since in CUBRID there is one cub_server process running for each database, system administrators can monitor each useros DB process. Moreover, you can limit the number of connections per a single user by assigning a broker to each of them.
- Administration Tool: currently we provide only two administration tools: one is CUBRID Manager, the other is CUBRID WebQuery. We have already started the development of phpCubridAdmin, and analogue for popular phpMyAdmin. So, please wait a little more. We are working hard on bringing it to you by mid 2011.
3.Configuration
Below you can see two different architectures hosting companies can use to provide the CUBRID database hosting. Basically, they are similar to that of original CUBRID architecture.
Architecture 1
This architecture proposes a hosting service solution consisting of a single CUBRID Server machine with N number of brokers for N number of users. Thus, you can control the number of client connections per user by configuring each broker parameters.
However, you cannot use full resources in the system because each broker process consumes default resources all the time.
Architecture 2
In this architecture, a single broker handles connections from many users. However, for efficient system resources management (this is one reason why CUBRID is optimized for Web applications), CUBRID's broker is designed to manage connection pooling and load balancing. Therefore, if a certain useros web service will drive more traffic than other users' and heavily load the database server, this will affect rest of userso services, too. Thus, this architecture is good for small-sized services.
4. Scripts
Script list
| Category | Script file name | Description |
| Hosting User Related | makedb.sh | Script for creating a database and DB user |
| removed.sh | Script for deleting a database | |
| chpwdb.sh | Script for changing DB useros password | |
| DB Admin Related | listdb.sh | Script for listing name of all databases |
| backupdb.sh | Script for DB Backup | |
| restored.sh | Script for DB Restore |
Script Details
makedb.sh
| Creating a new database | |
| Prototype | ./makedb.sh <userid> <password> |
| Parameter | Userid: Database name and its username Password: DB user’s password of the new database |
| Etc. | CUBRID creates DB user (DBA/PUBLIC user) by default. You should change each password in the DBA_PASS, PUBLIC_PASS parameter in the script. |
removedb.sh
| Removing a database | |
| Prototype | ./removedb.sh <userid> |
| Parameter | Userid: Database name to remove |
| Etc. |
chpwdb.sh
| Changing a DB user’s password | |
| Prototype | ./chpwdb.sh <dbname> <userid> <password> |
| Parameter | Dbname: database name to change Userid: username to change Password: new password of the user |
| Etc. | You should set the value of DBA_PASS parameter in the script. |
listdb.sh
| List all name of existing databases in the server | |
| Prototype | ./listdb.sh |
| Parameter | |
| Etc. | Each database name is listed by a collon delimiter ( : ). |
backupdb.sh
| Backup the database | |
| Prototype | ./backupdb.sh <dbname> |
| Parameter | dbname: database name to backup |
| Etc. |
restored.sh
| Restore the database | |
| Prototype | ./restored.sh <dbname> |
| Parameter | dbname: database name to restore |
| Etc. |
5. Suggestions
Unfortunately we do not know well how hosting infrastructure is configured and what its internal workflow is. Therefore, if you have any sugguestions how we can improve CUBRID so that it is easy to use in the hosting environment, please let us know on Twitter or CUBRID Forum. We are willing to know and gather more information on hosting services. If you request any materials or features, we will do our best to deliver them to you as soon as possible.