Distributed | Configuration detection of what was done when dble started

Author: Wu Jinling

A member of the Acsen dble project team, mainly responsible for the daily testing work related to dble, and is good at troubleshooting problems in dble. I love testing work, and I want to carry out the testing work to the end for the rest of my life.

Source of this article: original contribution

*The original content is produced by the open source community of Aikesheng, and the original content shall not be used without authorization. For reprinting, please contact the editor and indicate the source.

---

This article is dedicated to new fans of dble. When using dble for the first time, novices often encounter dble startup failures, and startup failures are generally caused by incorrect configuration. As we all know, dble fails to start, we can go to the wrapper.log to find the reason for the startup failure, and the good news is that we can generally find the reason for the startup failure from the wrapper.log. However, the reasons for a few startup failures are not so intuitive. In order to quickly locate and solve the problem, we need to understand what dble does when it starts. This article takes version 3.22.01.0 as an example to briefly introduce how dble verifies the correctness of the configuration file when it starts up.

For details, please refer to the official documentation of dble: https://actiontech.github.io/dble-docs-cn/1.config_file/1.00_config_file.html .

1. First, let us briefly understand what configuration files dble has and what their main functions are

Download the installation package of version 3.22.01.0, unzip it and enter the root directory of the dble installation directory, where there is a conf configuration file directory (there are template files in common configuration files). From the configuration file directory, we can see that dble is mainly divided into There are 4 types of configuration files (.cnf, .xml, .properties, .txt). The main functions of each configuration file are as follows:

file name	main effect	be careful	Reference link
cluster.cnf	Cluster parameter configuration file	Modifying this file requires stopping multiple dble instances, reinitializing cluster metadata, and then starting dble one by one	https://actiontech.github.io/dble-docs-cn/1.config_file/1.01_cluster.cnf.html
bootstrap.cnf	The system parameter configuration file loaded when the dble instance starts	The file is divided into two parts, the first part is the JVM startup parameters, and the second part is the dble system parameters	https://actiontech.github.io/dble-docs-cn/1.config_file/1.02_bootstrap.cnf.html
bootstrap.dynamic.cnf	Generally, it is a system parameter that can be thermally effective through management commands.	When dble restarts, the corresponding value in bootstrap.cnf will be replaced to take effect.	https://github.com/actiontech/dble-docs-cn/blob/master/1.config_file/1.02_bootstrap.cnf.md
user.xml	Login user profile (dble is mainly divided into four types of users)	Mainly pay attention to the configuration of sql permissions and ip whitelist	https://actiontech.github.io/dble-docs-cn/1.config_file/1.03_user.xml.html
db.xml	Configuration files for backend databases and groups	In order for dble to work properly, the back-end MySQL user needs to enable specific permissions	https://actiontech.github.io/dble-docs-cn/1.config_file/1.04_db.xml.html
sharding.xml	Configuration files for virtual libraries, tables, algorithms	Pay attention to the configuration method of the global sequence	https://actiontech.github.io/dble-docs-cn/1.config_file/1.05_sharding.xml.html
sequence_conf.propertie	Global sequence configuration file in distributed offset-step mode	Combined with cluster.cnf configuration, sequenceHandlerType=4	https://actiontech.github.io/dble-docs-cn/1.config_file/1.7_global_sequence/1.7.4_distribute_offset-step.html
sequence_db_conf.properties	Global sequence configuration file in MySQL-offset-step mode	Combined with cluster.cnf configuration, sequenceHandlerType=1	https://actiontech.github.io/dble-docs-cn/1.config_file/1.7_global_sequence/1.7.1_MySQL-offset-setp.html
.txt file	Configuration files corresponding to different sharding algorithms	Commonly used, please refer to the documentation for configuration when needed	https://actiontech.github.io/dble-docs-cn/1.config_file/1.05_sharding.xml.html
log4j2.xml	Log archiving rules and logging level configuration	When an error occurs, the log level can be adjusted to debug to locate detailed error information	https://actiontech.github.io/dble-docs-cn/1.config_file/1.06_log4j2.xml.html
cacheservice.properties	The total configuration file of dble's cache	Not commonly used, you can refer to the documentation for configuration when needed	https://actiontech.github.io/dble-docs-cn/1.config_file/1.8_cache/1.8.1_cache_setting.html
ehcache.xm	dble's cache implementation configuration file	Not commonly used, you can refer to the documentation for configuration when needed	https://actiontech.github.io/dble-docs-cn/1.config_file/1.8_cache/1.8.2_ehcache_setting.html
The jar package in the $DBLE_HOME/lib directory	Custom Split Algorithm File	Not commonly used, you can refer to the documentation for configuration when needed	https://actiontech.github.io/dble-docs-cn/1.config_file/1.09_dble_route_function_spec.html
dble_alert.properties	Custom Alert Profile	Not commonly used, you can refer to the documentation for configuration when needed	https://actiontech.github.io/dble-docs-cn/1.config_file/1.11_customized_alert.html

2. The following is a description of what detection dble does when loading the configuration file by listing several examples of dble startup failures that new fans often encounter

1. First start dble with the following boostrap.cnf configuration as an example (please configure other configuration files as needed, omitted here):

Enter the root directory of the dble installation, execute the dble startup command bin/dble start, and then execute bin/dble status to check the status of dble, and found that the startup failed:

Enter the wrapper.log to view, and find that the error is as follows:

As can be seen from the log, the error is due to port 22 being occupied. This is because dble initializes a virtual machine at startup and reads JVM parameters from bootstrap.cnf. During the startup process of dble, three ports will be occupied: business port (default 8066), management port (default 9066), and jvm provides jmx service port externally, so these three ports cannot be the same during configuration, and cannot be occupied by other programs. Specific reference: https://actiontech.github.io/dble-docs-cn/A.Faq/ErrorCode/Content/PortAlreadyInUse1984.html . So change the port to an unoccupied port to start successfully.

2. Start with the following boostrap.cnf configuration (please configure other configuration files as needed, omitted here):

It is found that dble starts to report an error, and the error message is as follows:

As you can see from the logs, there are 4 errors here:

• There is a space between -D and the parameter name "NIOFrontRW", which does not meet the requirements of JSW for configuration files, that is, there cannot be spaces. For details, please refer to https://wrapper.tanukisoftware.com/doc/english/prop-app -parameter-n.html#file ;
• The attribute value type of sqlExecuteTimeout is wrong. It should be of long type here, and it is mismatched to a character type. Change "30s" to "30";
• Wrongly spelled "frontWorker" as "frontWorkers". Note that the property names in the bootstrap.cnf file must be written in strict accordance with the document, and the capitalization must be strictly consistent, otherwise an error will be reported;
• The value of fakeMySQLVersion is incorrect, just rewrite "5.7" to "5.7.26".

3. For the xml file, dble will also check the configuration file format, attribute name, attribute value, attribute type, etc. when it is started, which will not be repeated here. In addition, for db.xml, dble will also detect the connectivity of the back-end MySQL nodes when it is started, and will also obtain the version numbers and case-sensitive parameter values of all back-end MySQL nodes.

dble is started with the following db.xml configuration (please configure other configuration files as needed, omitted here):

It was found that dble failed to start, check the wrapper.log log, and found the following errors:

This error indicates that the backend MySQL node connection detection failed. For this kind of error, the common troubleshooting method is to use the MySQL client to log in to the back-end MySQL node according to the connection parameters in the configuration, as follows:

This is because the connection port is incorrectly configured. Change the connection port "3306" of the database to "3307" to start successfully. This kind of error may also be caused by the wrong user and password, or because the user does not have permission. For specific possible reasons and solutions, please refer to: https://actiontech.github.io/dble-docs-cn/A.Faq/ErrorCode /Content/Can%27tGetVariablesFromShardingNode.html .

4. dble is started with the following db.xml configuration (please configure other configuration files as needed, omitted here):

When dble starts, an error is reported, and the error reported in the wrapper.log is as follows:

The above error message indicates that the back-end MySQL nodes have inconsistent case-sensitive parameter values. When dble starts, it will obtain the case-sensitive parameter value of all nodes according to the configuration of db.xml. dble requires that the parameter value must be consistent in all MySQL nodes, otherwise an error will be reported. After changing the case in hostM1 to be sensitive, dble can start successfully.

5. dble is started with the following bootstrap.cnf configuration (please configure other configuration files as needed, omitted here):

It was found that dble failed to start, and the following error was reported in the wrapper.log:

The error indicates that the version value configured in dble is higher than the version value of the backend node. This is because dble will obtain the MySQL version of all nodes configured in db.xml at startup, and then compare it with the fakeMySQLVersion configured in bootstrap.cnf. The value of fakeMySQLVersion required to be configured cannot be higher than the minimum version number of the back-end MySQL node. , otherwise an error will be reported.

In addition to the examples listed above, dble will also perform special checks on other configuration files, such as the correctness of the sharding algorithm, the correct pairing of user types and instance groups, and maxPacketSize synchronization. An example, because the general dble startup failure can be resolved through the error message in the wrapper.log.

In short, dble will check the validity of all configuration files when it starts, including the format of the configuration file, attribute name, attribute type, attribute value, etc. The back-end MySQL node will also be tested for connectivity, case consistency detection, fakeMySQLVersion validity detection, maxPacketSize synchronization, etc. It will also verify whether the configuration files are correctly configured and so on.