Typical Application Scenarios and Configurations
Log Diagnosis
ODBC logs are classified into unixODBC driver manager logs and gsqlODBC driver logs. The former is used to trace whether the application API is successfully executed, and the latter is used to locate problems based on DFX logs generated during underlying implementation.
The unixODBC log needs to be configured in the odbcinst.ini file:
1 2 3 4 5 6 7 |
[ODBC] Trace=Yes TraceFile=/path/to/odbctrace.log [GaussMPP] Driver64=/usr/local/lib/gsqlodbcw.so setup=/usr/local/lib/gsqlodbcw.so |
For gsqlODBC logs, you only need to add the following content to odbc.ini:
[gaussdb] Driver=GaussMPP Servername=10.10.0.13 # Database server IP address ... Debug=1 # Enable the debug log function of the driver.

The unixODBC logs are generated in the path configured by TraceFile. The gsqlODBC generates the mylog_xxx.log file in the /tmp/ directory.
Automatic Primary/Standby Switchover
Example Scenario
If a database instance is configured with one primary DN and multiple standby DNs, write the IP addresses of all DNs into the configuration file. ODBC automatically searches for the primary DN and establishes a connection with it. When a primary/standby switchover occurs, ODBC can also connect to the new primary DN.
Read on the Standby Node
Example Scenario
If a database instance is configured with one primary DN and multiple standby DNs, write the IP addresses of all DNs into the configuration file and set TargetServerType to standby or prefer-standby.
[gaussdb] Driver=GaussMPP Servername=10.145.130.26,10.145.130.27,10.145.130.28 # IP addresses of all DNs. Database=db1 # Database name. Username=omm # Database username. Password=******** # Database user password. Port=8000 # Database listening port. TargetServerType=standby # Connect to standby DNs.
Connection Pool Scenario
The connection pool allows applications to reuse pre-established connections without re-establishing connections each time. Once a connection is created and put into the connection pool, the application can reuse the connection, avoiding repeated execution of the complete connection process.
The use of connection pool can significantly improve performance, especially for middle-layer applications or applications requiring network connections that need to establish and close connections frequently.
In addition to the performance advantage, the connection pool architecture enables connections in the environment to be shared by multiple components in a single process. This means that different components in the same process can share connections in the connection pool without interfering with each other, further improving system efficiency and resource utilization.

In a connection pool, an open connection may be reused by multiple users. If your application script changes the database connection status, data leakage may occur. For security purposes, exercise caution when using a connection pool.
Configuration in the Linux OS
Enable the connection pool in the odbcinst.ini configuration file. The reference configuration of the connection pool is as follows:
[ODBC] Pooling=Yes # Enable the connection pool. [GaussMPP] CPTimeout=60 # Timeout for releasing a connection that is not reused in the connection pool. The default value is 0. To enable the connection pool, set this parameter to a value greater than 0. CPTimeToLive=60 # Lifetime of the connection pool under the driver. [GaussMPP2] CPTimeout=0 # Disable the connection pool.
Configuration in the Windows OS
On the Connection Pool tab, double-click GaussDB Unicode, and select Pool Connections to this driver (the default value is 60s). This parameter is the same as CPTimeout configured in the Linux OS. The reference figure is as follows.

- To configure the connection pool parameters in the application, you need to call SQLSetEnvAttr to set the connection pool parameters before creating the environment handle. The environment handle must be set to null, which makes SQL_ATTR_CONNECTION_POOLING a process-level attribute. Currently, SQL_ATTR_CONNECTION_POOLING can be set to either of the following values in the Windows OS:
- SQL_CP_OFF: The connection pool is disabled. This is the default value.
- SQL_CP_ONE_PER_DRIVER: Enable the connection pool. Each driver supports a connection pool, and all connections in the driver share the same connection pool.
- When an application calls SQLConnect or SQLDriverConnect, the connection is extracted from the connection pool. If the connection times out or no connection matches the request in the pool, a new connection is opened. The connection pool is transparent to the application.
- When an application calls SQLDisconnect, the connection is not released but put back to the connection pool for the next use.
- Before SQLFreeHandle is called in the environment to release the environment handle, all environment attributes that are successfully set by the application persist.
- If a connection of an application is inactive (not used) for a period of time, the connection is deleted from the pool. The size of the connection pool is limited only by the memory and server.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot