All Products
Search

This Product

    PolarDB:FAQ about parameter configuration

    Document Center

    PolarDB:FAQ about parameter configuration

    Last Updated:May 19, 2025

    How do I enable the binary logging feature for a PolarDB cluster?

    By default, the binary logging feature is disabled in PolarDB clusters. To enable the binary logging feature, set the loose_polar_log_bin parameter to ON in the PolarDB console. For more information, see Enable binary logging.

    Note

    • After the binary logging feature is enabled for a PolarDB cluster, the cluster is automatically restarted. During the restart, the cluster may encounter 1-minute transient disconnections. The time required to restart a PolarDB cluster varies from several minutes to several hours based on the amount of business data. We recommend that you enable the binary logging feature during off-peak hours and make sure that your application can automatically reconnect to the PolarDB cluster.

    • When you pull, subscribe to, or replicate binary logs by using services such as Data Transmission Service (DTS), we recommend that you use the primary endpoint of the PolarDB cluster. This ensures compatibility and stability because the primary endpoint connects to the primary node that generates binary logs.

    • When you commit large transactions after you enable the binary logging feature, the commission of other transactions may be blocked, and the restart and configuration change duration of the cluster may be affected.

    • The loose_polar_log_bin parameter is a global parameter. The sql_log_bin parameter specifies whether to enable or disable the binary logging feature at the session level. To prevent binary log data loss, the system forbids the modification of this parameter.

    Retention policies

    The following retention policies are supported for binary log files:

    • If the binary logging feature is enabled, binary log files are retained for three days by default. The binary log files whose retention period exceeds three days are automatically deleted.

      Note

      • For a PolarDB for MySQL cluster that was purchased before November 23, 2023, binary log files are retained for two weeks (14 days) by default.

      • For a PolarDB for MySQL cluster that was purchased before January 17, 2024, binary log files are retained for one week (seven days) by default.

    • If the binary logging feature is disabled, existing binary log files are permanently retained.

    Modify the retention period

    Important

    • Changing the retention period of binary log files does not disrupt connections or require a cluster restart.

    • However, if a large volume of binary log files such as 10 TB needs to be purged due to a change in retention period, brief exceptions may occur during write operations. If a large volume of binary logs exists, we recommend that you change the retention period during off-peak hours. You can also progressively shorten the retention period. This way, only a part of binary logs is cleared each time. This mitigates the impact on your business operations.

    • Deleted binary log files cannot be restored.

    • If the binary logging feature is enabled for your cluster, perform the following operations to change the retention period of binary logs:

      • PolarDB for MySQL V5.6 cluster: Change the value of the loose_expire_logs_hours parameter. Valid values of this parameter: 0 to 2376. Unit: hours. Default value: 72. A value of 0 specifies that binary log files are not automatically deleted. For more information, see Configure cluster and node parameters.

      • PolarDB for MySQL 5.7 or 8.0 cluster: Change the value of the binlog_expire_logs_seconds parameter. Valid values of this parameter: 0 to 4294967295. Unit: seconds. Default value: 259200. A value of 0 specifies that binary log files are not automatically deleted. For more information, see Configure cluster and node parameters.

        Important

        After you change the values of these two parameters, historical binary logs in your cluster are not immediately cleared. You can use one of the following methods to trigger immediate purging:

        • Wait for the rotation of binary log files. When the active binary log file reaches the maximum size set by max_binlog_size, a new binary log file is created and all historical binary log files are automatically deleted.

        • Use the privileged account to run the flush binary logs command.

        • Restart the cluster. Historical binary log files are cleared after the cluster restarts.

    • If the binary logging feature is disabled for your cluster and you want to delete binary log files, perform the following steps: Enable the binary logging feature for your cluster. For more information, see Enable binary logging. Set the loose_expire_logs_hours or binlog_expire_logs_seconds parameter to a smaller value, and wait for binary logs to expire and be automatically purged. Then, disable the binary logging feature.

    How do I configure parameters for a PolarDB cluster?

    For more information, see Configure cluster and node parameters.

    How do I enable the monitoring feature for my cluster?

    You can use one of the following methods to enable the monitoring feature for your cluster:

    • Set the loose_polar_performance_schema parameter to ON and restart your cluster. In this case, the Polar performance schema feature takes effect on databases in your cluster. For more information, see View the DDL statement execution status and MDL status. The Polar performance schema feature monitors database performance, allows you to view the DDL statement execution status and MDL status, and provides the performance_schema parameter to collect and display performance monitoring data. For more information, see Configure cluster and node parameters.

    • You can activate Database Autonomy Service (DAS) for your cluster. For more information, see Auto scaling by using DAS.

      Important

      If you activate DAS for your cluster, you do not need to enable the performance_schema parameter. If the parameter is enabled, additional memory is occupied, resulting in increased memory usage.

    After I modify a parameter, the system consistently indicates that the modification is still in progress. What may cause this situation? How do I resolve this issue?

    If a parameter modification remains in the in-progress state, the issue may be due to the following causes:

    • The modified parameter depends on other parameters. For example, to enable the hotspot feature, you must enable the binary logging feature. The value of the innodb_io_capacity parameter is limited by the value of the innodb_io_capacity_max parameter.

    • The modified parameter conflicts with another parameter, and you cannot enable the parameters at the same time. For example, the loose_hotspot and rds_ic_reduce_hint_enable parameters conflict with each other. To enable the loose_hotspot parameter, you must first disable the rds_ic_reduce_hint_enable parameter. You cannot enable the loose_polar_log_bin and innodb_trx_resume parameters at the same time.

    • The modified parameter is not supported by the current version. You must upgrade the cluster or cancel the parameter modification task.

    If the parameter modification task fails, Submit a ticket to contact technical support.

    After I modify a timeout parameter, the change does not take effect. Why?

    Check whether the timeout parameter you modify is a global parameter or a session parameter. The change to a global timeout parameter does not require a cluster restart. However, the change takes effect only for sessions established after the modification. For example, if you modify the innodb_lock_wait_timeout=180 parameter for the entire database, you don't need to restart the cluster.

    Note

    If you want to modify a parameter that requires a cluster restart, perform the operation during off-peak hours and make sure that your application is configured to automatically reconnect to the instance.

    How do I enable the event_scheduler parameter?

    By default, the event_scheduler parameter is enabled only for the primary node. You can connect to the primary node and check whether the parameter is enabled by executing the SHOW GLOBAL VARIABLES LIKE '%event_scheduler%'; statement.

    After I modify the collaction_server parameter, the ParamCollationServerNotValid error is reported. Why?

    The collation specified by the collation_server parameter must belong to the character set specified by the character_set_server parameter. You must first specify character_set_server and then specify collation_server.

    Does a parameter modification take effect globally? Can I modify parameters only for a node?

    • If you modify a global parameter, the modification takes effect for the entire cluster.

    • You can modify only non-global parameters for a specific node.

    How much time is required to restart a cluster after I modify a parameter that requires the cluster to restart?

    If you modify a parameter that requires the cluster to restart, you cannot cancel the restart operation. The amount of time required to restart a cluster varies from several minutes to several hours based on the amount of business data. We recommend that you restart a cluster during off-peak hours and make sure that your application can automatically reconnect to the cluster. You can schedule the parameter modification task to run within the maintenance window of the cluster. For information about how to restart a node, see Manage nodes.

    Does a parameter modification take effect immediately? Can I specify the effective time of the parameter modification?

    A parameter modification immediately takes effect after the parameter modification task is completed. If you do not want the parameter modification to immediately take effect, you can schedule the parameter modification task to run within the maintenance window of the cluster. If you want to modify a parameter at a specific time outside the maintenance window, you can call the ModifyDBNodesParameters operation to modify the parameter. For more information, see ModifyDBNodesParameters.

    How do I configure parameters to improve performance?

    • If you want to improve query performance, we recommend that you enable the hot row optimization feature. For more information, see Hot row update optimization.

    • If your cluster runs MySQL 8.0, you can use the high-performance parameter template feature. For more information, see High-performance parameter templates.

    How do I cancel a scheduled parameter modification task?

    You can cancel scheduled parameter modification tasks on the Scheduled Tasks page in the PolarDB console. For more information, see Scheduled tasks.

    Can I modify parameters for a serverless cluster with defined specifications?

    No. For more information, see the Usage notes section in Enable the serverless feature for a cluster with defined specifications.