ProxySQL 使用情况报错问题汇总及解决办法
1.ProxySQL Error: connection is locked to hostgroup 2 but trying to reach hostgroup 1
解决方案：登上proxysql的管理端执行以下命令
set mysql-set_query_lock_on_hostgroup=0;
#修改后，需要加载到RUNTIME，并保存到disk
load mysql variables to runtime;
save mysql variables to disk;
# 也可以在安装后尚未启动时修改配置文件，增加上这个参数：
mysql_variables=
{
......
set_query_lock_on_hostgroup=0
}
2.java.sql.SQLException: Unknown system variable query_cache_size
解决方案：proxysql 2.4.1版本目前内置的mysql版本也才是5.5.30的，所以如果你的数据库是8.0及以上的，一定要记得修改proxysql内置mysql的版本号，登上proxysql的管理端执行以下命令
update global_variables set variable_value="8.0.29" where variable_name='mysql-server_version';
#修改后，需要加载到RUNTIME，并保存到disk
load mysql variables to runtime;
save mysql variables to disk;
# 也可以在安装后尚未启动时修改配置文件，更新这个参数：
mysql_variables=
{
......
server_version="8.0.29"
}
3.配置文件中添加如下参数，启动失败，报语法错误
mysql_variables=
{
......
default_charset='utf8mb4'
default_collation_connection='utf8mb4_general_ci'
}
5月 25 17:28:45 k8s-develop-manager systemd[1]: Starting High Performance Advanced Proxy for MySQL...
5月 25 17:28:45 k8s-develop-manager proxysql[14792]: Parse error at /etc/proxysql.cnf:87 - syntax error
5月 25 17:28:45 k8s-develop-manager systemd[1]: proxysql.service: control process exited, code=exited status=1
5月 25 17:28:45 k8s-develop-manager systemd[1]: Failed to start High Performance Advanced Proxy for MySQL.
5月 25 17:28:45 k8s-develop-manager systemd[1]: Unit proxysql.service entered failed state.
5月 25 17:28:45 k8s-develop-manager systemd[1]: proxysql.service failed.
解决办法：
这俩变量的值默认是
mysql> select * from global_variables;
+----------------------------------------------------------------------+--------------------------------------------+
| variable_name | variable_value |
+----------------------------------------------------------------------+--------------------------------------------+
| mysql-default_charset | utf8 |
| mysql-default_collation_connection | utf8_general_ci |
启动之前配置文件中先不添加的，等程序启动后，手动修改
set mysql-default_charset='utf8mb4';
set mysql-default_collation_connection='utf8mb4_general_ci';
load mysql variables to runtime;
save mysql variables to disk;
mysql> select * from global_variables;
+----------------------------------------------------------------------+--------------------------------------------+
| variable_name | variable_value |
+----------------------------------------------------------------------+--------------------------------------------+
| mysql-default_charset | utf8mb4 |
| mysql-default_collation_connection | utf8mb4_general_ci |
4.查看proxySQL ping日志，发现监控账户连接数据库失败，报错如下：
mysql> select * from mysql_server_ping_log;
+---------------+------+------------------+----------------------+---------------------------------------------------------------------------------------------------------------------------+
| hostname | port | time_start_us | ping_success_time_us | ping_error |
+---------------+------+------------------+----------------------+---------------------------------------------------------------------------------------------------------------------------+
| 192.168.0.218 | 3306 | 1653471251681522 | 0 | Aborted connection 2616 to db: 'unconnected' user: 'proxysql_monitor' host: '192.168.0.218' (init_connect command failed) |
| 192.168.0.36 | 3306 | 1653471251826419 | 0 | Aborted connection 429 to db: 'unconnected' user: 'proxysql_monitor' host: '192.168.0.218' (init_connect command failed) |
解决方案：
根据报错信息：init_connect command failed进行排查，发现是后端MySQL数据库配置文件中有个参数：init_connect=’SET NAMES utf8mb4’，使用的单引号符号不对才导致连接报错的
修改该参数配置为：init_connect='SET NAMES utf8mb4'，重启MySQL，proxySQL ping日志就不会再报错了
自动回避复制延迟较大的节点
查看proxysql运行日志，会有如下信息
2022-05-27 15:53:41 MySQL_Monitor.cpp:2375:monitor_replication_lag_thread(): [ERROR] Replication lag on server 192.168.20.200:3306 is NULL, using the value 60 (mysql-monitor_slave_lag_when_null)
原因分析：
proxyql的mysql_servers表中设置了主库max_replication_lag的值，但是主库中没有show slave status中的Seconds_Behind_Master字段值，因此会报主库拖后腿，其实主库不需要设置max_replication_lag的值
Monitor模块会监控后端主机组中各slave的数据是否延迟于master，这个延迟行为称为replication lag，俗称拖后腿。
如果某个slave节点上的数据比master落后很多(临界值见下文)，表示这个slave节点处理速度慢，数据较旧。ProxySQL采用一种称为自动避开(automatic shunned)的方式，临时避开这个落后的节点。当ProxySQL避开某节点后，ProxySQL不会把SQL语句路由给这个节点。
ProxySQL有几种情况可能会触发自动避开节点的行为：
- 和后端的连接断开。
- slave落后于master过多。
- 和后端建立连接时，错误次数过多。
- second_behind_master=null时，即slave的SQL线程未运行，或者slave未连接到master。(不过这种自动避开的情况是可控的，见全局变量mysql-monitor_slave_lag_when_null）
Monitor模块会每隔一段时间(mysql-monitor_replication_lag_interval)去检查一次拖后腿情况，检测的方式是获取show slave status中的Seconds_Behind_Master字段值，然后和mysql_servers表中max_replication_lag字段的值比较：
mysql> select * from global_variables where variable_name like 'mysql-monitor%lag%';
+-----------------------------------------------------+----------------+
| variable_name | variable_value |
+-----------------------------------------------------+----------------+
| mysql-monitor_replication_lag_group_by_host | false |
| mysql-monitor_replication_lag_interval | 10000 |
| mysql-monitor_replication_lag_timeout | 1000 |
| mysql-monitor_replication_lag_count | 1 |
| mysql-monitor_replication_lag_use_percona_heartbeat | |
| mysql-monitor_slave_lag_when_null | 60 |
+-----------------------------------------------------+----------------+
6 rows in set (0.01 sec)
- Seconds_Behind_Master < max_replication_lag：表示落后程度尚在允许范围内。
- Seconds_Behind_Master > max_replication_lag：表示落后太多，这样的节点应该避开。
只有传统复制结构的slave节点才需要设置max_replication_lag字段，master无需设置，组复制和galera也无需设置，因为这两种复制结构中show slave status的结果为空。例如，将读组中的所有节点都设置最多落后于master 10秒钟。
update mysql_servers set max_replication_lag=10 where hostgroup_id=20 and hostname="192.168.20.201"; # 确保条件限定从库
load mysql servers to runtime;
save mysql servers to disk;
select hostgroup_id,hostname,port,max_replication_lag from mysql_servers;
需要注意的是，Seconds_Behind_Master的值并不总是可靠的，见 https://dev.mysql.com/doc/refman/5.7/en/show-slave-status.html 。
意思是说主从数据库中，从库执行命令：show slave status的结果中有个参数：Seconds_Behind_Master
proxysql中mysql_servers表中有个字段max_replication_lag，这俩值相比较。
监控模块负责对后端进行一系列检查。它目前支持 4 种类型的检查：
1）connect ==> 它连接到所有后端 MySQL 服务，成功 / 失败将记录在表 mysql_server_connect_log 中；
2）ping ==> 它 ping 到所有后端的 MySQL 服务，并在表 mysql_server_ping_log 中记录成功 / 失败。如果丢失心跳的次数超过 mysql-monitor_ping_max_failures 值，则向 MySQL_Hostgroups_Manager 发送信号以终止所有连接；
3）replication lag ==> 它将检查配置了 max_replication_lag 大于 0 的所有后端 MySQL 的 Seconds_Behind_Master 值，并将检查结果记录在表 mysql_server_replication_lag_log 中。如果 Seconds_Behind_Master > max_replication_lag 则服务器被忽略，直到 Seconds_Behind_Master < max_replication_lag;
4）read only ==> 它检查表 mysql_replication_hostgroups 内记录的主机组中所有主机的 read_only 参数值，并将检查结果在记录表 mysql_server_read_only_log 中。
解决办法：
1.上述报错是因为主库也设置了max_replication_lag的值，更新为0。
2.修改proxysql中mysql_servers表中的从库Mmax_replication_lag的值为10.
最终效果
mysql> select hostgroup_id,hostname,port,max_replication_lag from mysql_servers;
+--------------+----------------+------+---------------------+
| hostgroup_id | hostname | port | max_replication_lag |
+--------------+----------------+------+---------------------+
| 100 | 192.168.20.200 | 3306 | 0 | # 主库
| 1000 | 192.168.20.201 | 3306 | 60 | # 从库
| 1000 | 192.168.20.200 | 3306 | 0 | # 主库
+--------------+----------------+------+---------------------+
3 rows in set (0.00 sec)
