posted last year in CUBRID Life category by Park Kieun
Some developers have already asked why there are a dozen processes being created when CUBRID is started. Being one of the core developers of CUBRID Database and creator of CUBRID Cluster project, I thought it was my duty to explain CUBRID processes and the communication between each of them. Frankly speaking, it is very easy to understand. This article is a part of a book I am writing called CUBRID Internals. I will publish the rest of the book in coming posts here at CUBRID Blog.
CUBRID is based on Client-Server DBMS architecture. Such architecture enhances processing speed and distributes DBMS functions to multiple hosts as several clients can cache the database object saved on the server. In CUBRID, the database server process (cub_server process linked to libcubrid.so) performs the storage system function while the client process (cub_cas process linked to libcbridcs.so) performs analysis, optimization, and creation of execution plan of query statements.
CUBRID consists of several processes. In MySQL, one mysqld process provides most functions; in Oracle, many processes starting with ora_ are running. CUBRID, like Oracle, has some processes starting with cub_.
As we have reviewed in CUBRID System Architecture, CUBRID is divided into database server and broker. Each of them consists of the following processes shown in Figure 1.
- A circle indicates a process including the process name and the dynamic shared library. For example, the cub_server process is linked to the shared library called "libcubrid.so".
- The rectangle indicates the DB file or configuration file such as cubrid.conf.
Figure 1: CUBRID Process Configuration.
CUBRID has one server process per DB called cub_server. A user uses it by specifying the DB name. cub_server process is a core process of CUBRID DBMS. It directly accesses the database volume file and transaction log file to process request from a client. cub_server is a multi-threaded process that can simultaneously process multiple requests. Generally, cub_cas and csql are the client processes that send requests to cub_server process. All of these client processes are linked to the libcubridcs.so shared library. The system configuration file used by cub_server is cubrid.conf.
cub_master is a master process for the CUBRID server process. It establishes a communication between the client and server processes. One master process is created for each connection port specified in cubrid.conf (
cubrid_port_id parameter). Each cub_master process listens to a specified TCP/IP port. This port is used by client processes to connect with the server process. According to the specified database name, a socket connection is sent to the corresponding cub_server process, and the communication between the client and server processes is started.
The cub_admin process performs database utility management functions such as
checkdb. According to a function, the cub_admin process can be executed in Client/Server mode (CS mode) or independent execution mode (SA mode); therefore, the shared library is dynamically loaded. This is called shared library dynamic loading. In other words, when the command is the CS mode utility command, the process is dynamically linked to the libcubridcs.so shared library; and when the command is the SA mode utility command, the process is dynamically linked to the libcubridsa.so shared library. For a more detailed description on database management utility, see CUBRID Utilities.
CUBRID broker provides various application programming interfaces (JDBC, PHP, CCI, etc.) to connect to a database server. cub_broker process establishes a socket connection to connect the JDBC or other APIs to the cub_cas process, figures out the status of the cub_cas process through the shared memory and allocates the cub_cas process distinguished by the application session. In addition, the cub_broker process adjusts the number of active cub_cas according to the setting values in the cubrid_broker.conf file for connection pooling between the application client and the database server.
cub_cas relays the requests from a variety of application clients such as JDBC driver, PHP driver or CCI library program (most requests are related to SQL execution) to the CUBRID database server and exchanges information with the cub_broker process through the shared memory. The cub_cas process is linked to the libcubridcs.so shared library and it runs in CS mode. Therefore, it is a client process for the cub_server process.
Now you know the purpose of each process which is created when CUBRID is started. There is another group of processes which belong to CUBRID Manager Server. But this is another talk as it is not a part of CUBRID Server itself. If you are interested, check out this question: "What is cub_js process for?"
In the next article I will explain about the Basic Operations in CUBRID, i.e. what happens what you start CUBRID, what order the processes are started in, and the like.
By Park Kieun, Senior Software Engineer and Architect at Service Platform Development Center & IT Service Center, NHN Corporation.