API节点常见问题

API节点常见问题

其他节点无法连接API节点怎么办？

如果其他节点（EdgeAdmin或者EdgeNode等）无法连接API节点，出现 connection error 类似错误，那么可以从以下几点来诊断问题：

检查API节点进程是否已经启动，通常可以通过 ps 命令来检查：
```
ps ax|grep edge-api
```
结果应该类似于：
```
[root@web001 ~]# ps ax|grep edge-api
3930 ?        Sl    65:32 /opt/www/edge-admin/edge-api/bin/edge-api
76969 pts/0    S+     0:00 grep --color=auto edge-api
```
其中 3930 就是edge-api的进程ID（不是固定的），如果没有这一行，则说明你的API节点没有启动，请执行 edge-api start 启动节点。
检查启动过程中有无错误，可以通过edge-api安装目录下的 logs/run.log 文件来查看启动日志：
```
tail -f logs/run.log
```
检查端口是否已监听，假设 8001 是你指定的API节点端口：
```
netstat -an|grep 8001|grep LISTEN
```
检查是否能返回内容。
检查是否有防火墙或者安全策略，可以在别的服务器上（比如边缘节点上）通过 telnet 检查是否能够连接API节点端口：
```
telnet 192.168.1.100 8001
```
其中 192.168.1.100 换成你的API节点所在服务器的IP，如果连接不了，通常是防火墙或者安全策略设置问题，请修改防火墙和安全策略设置；对于有些服务商提供的安全策略，不仅仅要设置API节点的入站策略，还要设置边缘节点的出站策略，都需要设置API节点的端口为通过。
检查数据库磁盘是否已满，虽然几率很小，但是仍然有不少用户因为这个问题导致edge-api无法启动，使用命令查看：
```
df -h
```
检查结果中的 Avail 列是否有为 0 的；
检查其他节点（比如边缘节点）的防火墙是否封禁了API节点的IP地址，比如因WAF规则设置错误，可能会导致误封。

修改API节点端口后，其他节点无法连接怎么办？

如果你修改了API节点端口（监听地址或访问地址），其他的节点（比如管理平台、边缘节点）中的配置文件 api.yaml 中的端口地址也需要手工更改成新的API节点端口。

如果想还原自己的设置，可以通过SQL语句：

use $安装数据库;
UPDATE edgeAPINodes SET http=JSON_SET(http, '$.listen[0].portRange', "8001");

把其中的 $安装数据库 换成你的实际安装用的数据库；8001就是安装时指定的端口。

修改后，需要重启edge-api进程，让配置生效。

出现Error 1461: Can’t create more than max_prepared_stmt_count statements错误怎么办？

出现这种情况，是因为MySQL服务的max_prepared_stmt_count参数值过小，可以通过重启API节点自动设置（在使用的MySQL用户有超级权限的情况下），或者在MySQL配置文件 my.cnf 中设置：

[mysqld]
...
max_prepared_stmt_count=65535
...

修改配置后，记得重启MySQL以便让配置生效。

如果你不知道 my.cnf 的位置，可以通过命令：

bin/mysql --verbose --help|grep cnf

来查看MySQL查找的所有配置文件位置。

如果暂时不方便重启MySQL服务，可以使用root用户连接MySQL，然后执行：

set global max_prepared_stmt_count=65535;

如果你有多个API节点连接同一个数据库，可能还需要将此值调整的更大一些，数值大概为每个10000 * API节点数量，比如你有10个API节点，那么这个值应该为100000。

如果你还有其他业务连接同一个数据库，也要适当增大此值。

升级时提示 query version failed: Error 1146: Table ‘edges. edgeVersions’ doesn’t exist

出现这个问题是因为 lower_case_table_names 设置错误，目前GoEdge支持的 lower_case_table_names 值只能是0（Linux/Unix）和2（macOS）。

MySQL binlog占用空间过大怎么办？

有时会发现MySQL数据库目录下binlog文件占用的文件过大，比如：

-rw-r----- 1 mysql mysql  22G Oct 10 16:32  binlog.000018
-rw-r----- 1 mysql mysql  21G Oct 30 16:50  binlog.000019

对于硬盘空间比较少的服务器会影响服务的正常运行。

对于这个问题，我们可以在MySQL配置中，比如my.cnf（有的叫 mysql-server.cnf）中设置binlog的过期时间，因为在绝大部分情况下，我们不需要回滚N天之前的数据。

对于MySQL v5.7.x，设置过期时间3天：

[mysqld]
...
expire_logs_days=3
...

对于MySQL 8.x.x，设置过期时间3天：

[mysqld]
...
binlog_expire_logs_seconds=259200
...

其中259200是时钟秒数。

修改配置后，重启MySQL服务生效。

重启MySQL服务后，可以使用SHOW VARIBLES来查看变量是否已经设置成功：

# v5.6.x
SHOW VARIABLES WHERE VARIABLE_NAME='expire_logs_days';
# v8.x.x
SHOW VARIABLES WHERE VARIABLE_NAME='binlog_expire_logs_seconds';

如何调用API节点中的API？

如果需要调用API节点中的API，可以参考 API 一节。

访问日志占用数据库空间太大怎么办？

设置服务访问日志自动清理，在”系统设置”菜单–“高级设置”菜单–数据库–自动清理设置中可以设置服务访问日志保留天数，可以根据根据你的访问量和数据库存储空间调整此值；
可以设置MySQL binlog的有效期，请参考本文的 MySQL binlog占用空间过大怎么办？；
可以添加多个日志数据库节点，这样可以将访问日志分多个数据库存储，请参考数据库节点。