CDN文档

API节点常见问题

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

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

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

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

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

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

use $安装数据库;
UPDATE cloud_api_nodes SET http=JSON_SET(http, '$.listen[0].portRange', "8001");
把其中的 $安装数据库 换成你的实际安装用的数据库；8001就是安装时指定的端口。

修改后，需要重启cloud-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。

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

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/9.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 一节。

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

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