posted last year in News category by Esen Sagynov
For those who have been using CUBRID 8.4.1 for production but wanted to get the hands on the latest features available in CUBRID 9.0 such as native support for Database Sharding, there is great news! We are announcing the immediate availability of CUBRID 8.4.3, the release fully compatible with 8.4.1 which introduces Database Sharding and API level Load Balancing features among others to 8.4.x family! You can download CUBRID 8.4.3 from the Downloads page.
Further I will explain in details all about the new features introduced in CUBRID 8.4.3.
CUBRID SHARD, which was first announced in CUBRID 9.0, is now available in CUBRID 8.4.3. CUBRID SHARD provides environmental convenience when processing a large volume of data by facilitating the access to horizontally partitioned databases across multiple servers. The CUBRID SHARD feature provides a single view that shows databases, which are spread across multiple nodes, as a single database, and transparency that allows users to recognize them without accessing individual databases. CUBRID SHARD is a great feature, and we are happy to include it in CUBRID 8.4.3.
Another great feature of CUBRID SHARD is that it supports MySQL as a backend database alongside CUBRID. For more information about this, read our previous blog where you can find a Slideshare presentation with more details.
API level Load Balancing
In CUBRID 8.4.3 we have added a new feature to CCI and JDBC drivers which allows applications to connect to the main host or the hosts specified by
althosts parameter in the connection URL in a random order. In the following example of a connection URL, this functionality is activated by setting the value of
loadBalance parameter to
true the driver will randomly choose a host among those specified in the connection URL except the one which was used to connect the last time, then the driver will try to connect to this randomly chosen host. If the chosen host is not available, the selection will continue until all the hosts are determined as unavailable. In such case, the driver will report an error.
Thus, CUBRID now provides two level Load Balancing:
- Server level when the CUBRID Broker balances the requests among multiple CUBRID Application Servers (CAS).
- API level when the driver randomly chooses a host to connect to, thus significantly offloading the main host server.
For more information refer to
New API functions
In addition to the Load Balancing we have also added two more APIs to our CCI driver.
cci_close_query_result()closes the result set returned by cci_execute(), cci_execute_array(), or cci_execute_batch() functions, thus allows to decrease the memory consumption at a given time.
cci_escape_string()escapes all unsafe characters so that the string can be safely used within an SQL statement.
In CUBRID 8.4.3 we have also added the
INET_NTOA SQL functions. These functions are available in CUBRID 9.0 as well. The
INET_ATON function returns a numeric value when an IPv4 address is entered, while the
INET_NTOA function returns an IPv4 address value when numbers are entered.
SELECT INET_ATON('192.168.0.10'); inet_aton('192.168.0.10') ============================ 3232235530 SELECT INET_NTOA(3232235530); inet_ntoa(3232235530) ====================== '192.168.0.10'
New Monitoring Functionality
Query execution status
CUBRID 8.4.3 now supports a new
-q option in
cubrid killtran command line utility which displays the execution time in seconds of those queries which are running at this moment of the time. This utility now shows information about:
- the transaction index
- the client process ID
- the client program name
- the total execution time of a query being executed in seconds
- the total execution time of the current transaction in seconds
- the list of transactions which hold the lock when the current transaction is in lock waiting
- the query statement being executed (up to 30 characters)
Logging slow queries
In CUBRID 8.4.3 we added a new system parameter
sql_trace_slow_msec which allows to log query statements, which have exceeded the specified execution time, together with their query execution plan. When the value of
sql_trace_slow_msec parameter is yes, the SQL statement, its query execution plan, and the
cubrid statdump information are recorded in the server error log file and the broker application server (CAS) log file. When the
cubrid plandump is executed, the corresponding SQL statement and the query execution plan are displayed. However, the corresponding information is recorded in the server error log file only when the value of the
error_log_level parameter is NOTIFICATION.
Now using this system parameter you can find slow queries and tune them faster.
API level debugging logs
Related to the above slow queries logging feature, in CUBRID CCI driver we have added several new connection URL parameters which can be used to instruct the driver whether or not slow queries must be logged. We have previously blogged about a similar feature in 8.4.1 which allows to log generic debugging logs. Now you can separately logs slow queries.
We have added:
slowQueryThresholdMillisparameters for this purpose which write slow query log information
logTraceApiwrites the beginning and the end of the called CCI functions
logTraceNetworkwrites the network data transmission information of a CCI function to a file.
In CUBRID 8.4.3 we have added the
check_peer_alive system parameter to set whether to check if the database server process (cub_server) and the client process that connected to the database server process have run normally or not.
The types of client processes include the broker application server (cub_cas) process, the replication log reflection server (copylogdb), the replication log copy process (applylogdb), and the CSQL interpreter (csql).
When a server process and a client process do not receive any response for a long time (e.g., 5 seconds or longer) after they have been connected while waiting for the data via the network, they check if the opponent operates normally or not depending on this configuration parameter. If they decide that the opponent does not operate normally, they force to disconnect the connection.
Built-in CUBRID Web Manager
This is one of the most important features we have added to CUBRID 8.4.3. CUBRID Web Manager (CWM) is the next generation SQL client with monitoring features that we announced two months ago. At the time CWM was not part of CUBRID but was distributed separately just like other CUBRID Tools.
However, today we are happy to announce that from now on CWM will be distributed together with CUBRID Engine. This means that once you start CUBRID Service with
cubrid service start command line utility, CWM will be started together and will be listening to secure (HTTPS) 8282 port (default but configurable). Just open your browser, navigate to https://localhost:8282 (or the remote host) and you can start managing and monitoring your CUBRID Server in real time with CUBRID Web Manager. This is awesome!
For more information about each of these new features, refer to CUBRID 8.4.3 Release Notes.