what

# 详细链接
SHOW FULL PROCESSLIST;

# 汇总查看
SELECT USER, COUNT(*) FROM information_schema.processlist GROUP BY USER;

然后生成查杀kill

SELECT CONCAT('KILL ', ID, ';') AS kill_command
FROM information_schema.processlist
WHERE USER = 'agent' AND COMMAND = 'Sleep';

如果你还想释放这些Sleep的连接。

MySQL 的 SQL 界面不支持直接执行由 SELECT 生成的 KILL 语句。可以按照以下步骤在 MySQL 命令行或脚本中批量执行这些 KILL 命令。

1. 在 MySQL 中生成 KILL 命令列表

首先，运行以下 SQL 语句生成所有 agent 用户的空闲连接的 KILL 命令：

SELECT CONCAT('KILL ', ID, ';') AS kill_command
FROM information_schema.processlist
WHERE USER = 'agent' AND COMMAND = 'Sleep';

这会生成类似以下输出：

KILL 123;
KILL 456;
KILL 789;

2. 批量执行生成的 KILL 命令

方法一：手动执行

从生成的结果中复制 KILL 命令，然后手动粘贴并执行。

方法二：使用 Shell 脚本批量执行

如果您有服务器的 Shell 访问权限，可以将这些命令导出到文件，并通过 MySQL 命令行批量执行。例如：

mysql -u root -p -e "SELECT CONCAT('KILL ', ID, ';') FROM information_schema.processlist WHERE USER = 'agent' AND COMMAND = 'Sleep';" > kill_commands.sql
mysql -u root -p < kill_commands.sql

这种方式会批量执行所有生成的 KILL 命令。

批量脚本

#!/bin/bash

# Redis服务器连接信息
REDIS_HOST="your_redis_host"
REDIS_PORT="your_redis_port"
REDIS_PASSWORD="your_redis_password"

# 初始化游标
cursor="0"

# 循环遍历所有key
while [ "$cursor" != "0" ]
do
    # 执行SCAN命令
    result=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASSWORD --scan --pattern "*" count 1000)
    cursor=$(echo "$result" | head -n 1)
    keys=$(echo "$result" | tail -n +2)

    for key in $keys
    do
        ttl=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASSWORD TTL $key)
        if [ "$ttl" -eq -1 ]; then
            echo "Key with no expiration: $key"
        fi
    done
done

使用下面的代码，将从游标 0 开始扫描 1000 个对象

SCAN 0 MATCH "foo:bar:*" COUNT 1000

结果，将获得一个要调用的新光标：

SCAN YOUR_NEW_CURSOR MATCH "foo:bar:*" COUNT 1000

要扫描整个列表，你需要调用 SCAN 直到光标返回零（即整个扫描）

使用 INFO 命令获取密钥数量，例如：

db0:keys=YOUR_AMOUNT_OF_KEYS,expires=0,avg_ttl=0

然后调用：

SCAN 0 MATCH "foo:bar:*" COUNT YOUR_AMOUNT_OF_KEYS

cd /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots
mv 41689 /tmp

移除就好了。

对应的是pod的.metadata.uid：

for d in /var/lib/kubelet/pods/*; do
  p_u=$(basename "$d")
  kubectl get po -A -o json | \
    jq --arg pod_uuid "$p_u" -r '.items[] 
      | select(.metadata.uid == $pod_uuid) 
      | "uuid \($pod_uuid) is \(.metadata.name)"'
done

类似如下输出：

"Labels": {
    "annotation.io.kubernetes.container.hash": "e44bee94",
    "annotation.io.kubernetes.container.restartCount": "4",
    "annotation.io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
    "annotation.io.kubernetes.container.terminationMessagePolicy": "File",
    "annotation.io.kubernetes.pod.terminationGracePeriod": "30",
    "io.kubernetes.container.logpath": "/var/log/pods/kube-system_storage-provisioner_b4aa3b1c-62c1-4661-a302-4c06b305b7c0/storage-provisioner/4.log",
    "io.kubernetes.container.name": "storage-provisioner",
    "io.kubernetes.docker.type": "container",
    "io.kubernetes.pod.name": "storage-provisioner",
    "io.kubernetes.pod.namespace": "kube-system",
    "io.kubernetes.pod.uid": "b4aa3b1c-62c1-4661-a302-4c06b305b7c0",
    "io.kubernetes.sandbox.id": "3950ec60121fd13116230cad388a4c6c4e417c660b7da475436f9ad5c9cf6738"
}

在Kubernetes中，无状态应用通常指的是应用程序的设计方式，使其在集群中的任何节点上都能够无缝运行，而不依赖于特定节点的本地存储或状态信息。这种设计有助于实现高可用性、伸缩性和容错性。Kubernetes是一个开源的容器编排平台，用于自动化容器化应用程序的部署、扩展和管理。

无状态应用在Kubernetes中的主要特征包括：

1. 无状态容器： 应用程序的组件被打包为容器，并设计为无状态的。容器应该包含所有应用程序所需的依赖项，并且不应该依赖于本地存储或节点上的任何状态信息。

2. 自动伸缩： 无状态应用可以更容易地实现自动伸缩。Kubernetes可以根据负载情况自动调整应用程序的副本数量，以满足性能需求。

3. 高可用性： 由于无状态应用不依赖于本地状态，因此它们可以在集群中的任何节点上运行。如果某个节点故障，Kubernetes可以重新调度应用程序的副本到其他健康的节点上，实现高可用性。

4. 简化部署： 无状态应用的部署更为简单，因为它们不需要在节点之间同步状态信息。这使得应用程序更易于扩展和更新。

在Kubernetes中，无状态应用通常指的是应用程序的设计方式，使其在集群中的任何节点上都能够无缝运行，而不依赖于特定节点的本地存储或状态信息。这种设计有助于实现高可用性、伸缩性和容错性。Kubernetes是一个开源的容器编排平台，用于自动化容器化应用程序的部署、扩展和管理。

无状态应用在Kubernetes中的主要特征包括：

1. 无状态容器： 应用程序的组件被打包为容器，并设计为无状态的。容器应该包含所有应用程序所需的依赖项，并且不应该依赖于本地存储或节点上的任何状态信息。

2. 自动伸缩： 无状态应用可以更容易地实现自动伸缩。Kubernetes可以根据负载情况自动调整应用程序的副本数量，以满足性能需求。

3. 高可用性： 由于无状态应用不依赖于本地状态，因此它们可以在集群中的任何节点上运行。如果某个节点故障，Kubernetes可以重新调度应用程序的副本到其他健康的节点上，实现高可用性。

4. 简化部署： 无状态应用的部署更为简单，因为它们不需要在节点之间同步状态信息。这使得应用程序更易于扩展和更新。

这是 Lettuce 的一项安全功能，目的是防止通过集群节点（CLUSTER NODES）重定向到（尚未）已知的节点。如果拓扑结构发生变化，而客户端有不同的视图，就会出现这种状态。

Redis在扩容/缩容过程中，当实例分片数发生变化时，存在节点拓扑关系和Slot对应信息的变化，需要客户端进行拓扑关系的自动更新，否则可能造成请求路由失败或者路由位置错误等，造成客户端访问报错。

1、开启Cluster集群自动刷新拓扑配置。

spring:
  redis:
    cluster:
      refresh:
        adaptive: true
        period: 30000    # 30秒自动刷新一次

2、关闭“验证集群节点成员资格开关”，关闭方式如下：

spring:
  redis:
    cluster:
      validate-cluster-node-membership: false

Calico的问题。
从 v3.26.0 升级到 v3.26.1 解决了这个问题。

你这么做是对的。

通常情况下，如kubectl scale deploy my-awesome-deployment --replicas=0，这样就不需要指定特定文件了，但如果对你来说更方便，使用文件也没有错。