Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 2 years ago
viewed 7698 times
Share this article

CUBRID 8.4.3 with DB Sharding and API level Load Balancing is here

cubrid_8.4.3.png

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.

Database Sharding

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.

Driver Features

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.

jdbc:cubrid:host1:port1:demodb:::?althosts=host2:port2,host3:port3&loadBalance=true

When loadBalance is 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 cci_connect_with_url() API.

New API functions

In addition to the Load Balancing we have also added two more APIs to our CCI driver.

Extended SQL

In CUBRID 8.4.3 we have also added the INET_ATON and 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:

  • logSlowQueries and slowQueryThresholdMillis parameters for this purpose which write slow query log information
  • logTraceApi writes the beginning and the end of the called CCI functions
  • logTraceNetwork writes the network data transmission information of a CCI function to a file.

For example:

url ="cci:cubrid:localhost:33000:demodb:::?logSlowQueries=true&slowQueryThresholdMillis=1000&logTraceApi=true&logTraceNetwork=true"

dd

New Configurations

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

cwm_monitors.png

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.

If you have questions, feel free to ask on our dedicated Q&A site, forum, Twitter, Facebook, Google+#cubrid IRC channel, or contact us by email. We will be glad to answer you!



comments powered by Disqus