pd日志报grpc: addrConn.createTransport failed to connect to

[Hacker_Lc1rnkne]

是的 ，这个日志是在194节点获取的，直到现在194还是在不停的尝试访问119

[2020/09/22 03:26:40.438 +02:00] [WARN] [grpclog.go:60] [“grpc: addrConn.createTransport failed to connect to {10.10.48.119:2379 0 }. Err :connection error: desc = “transport: Error while dialing dial tcp 10.10.48.119:2379: connect: no route to host”. Reconnecting…”]

谢谢

[Lucien-卢西恩 (路西恩)]

@Hacker_Lc1rnkne

Err :connection error: desc = “transport: Error while dialing dial tcp 10.10.48.119:2379: connect: no route to host”.

119 已经下线了嘛？看一下 member 状态是正常的么？有没有 119 还在么？

[Hacker_Lc1rnkne]

@SUN-PingCAP

119 已经下线了嘛？看一下 member 状态是正常的么？有没有 119 还在么？

你好，可以看下第三条回复，119已经下线了，member状态是正常的。

[yilong (yi888long)]

这个扩缩容，手工修改过run.sh 脚步？ 麻烦检查下各个脚步，是不是手工没有清理干净。建议尽快使用tiup.，方便操作。

[Lucien-卢西恩 (路西恩)]

@Hacker_Lc1rnkne

你好，可以看下第三条回复，119已经下线了，member状态是正常的。

根据你的反馈，我们其实怀疑可能是其他的服务 TiDB、TIKV、PD 的启动脚本里面包涵 119 的配置，所以需要帮忙排查；
另外上次抓取的信息，根据你的反馈，也怀疑是 119 节点信息在 PD cluster 集群里面没有清理干净，由于目前对集群正常使用没有影响，只是报错。如果有停机窗口，可以尝试重启一下 PD 集群，看看是否可以解决问题。

[Hacker_Lc1rnkne]

手工做过，每台pd都做过

[zhenjiaogao]

恩恩，辛苦了。

从上面使用 capture 工具抓到的信息没有看到 119 相关的内容，可能是抓取的时间段，pd 的 log 里面没有出现访问 119 的报错信息，能否将收集信息的时间段拉长，包括 pd 访问 119 的时间点，再次尝试帮忙拿下信息吧~~

另外，也请将 capture 工具抓取的目标 pd 相同时间段的 log 也帮忙取下吧~~

谢谢，谢谢~~

[Hacker_Lc1rnkne]

您好，我查了下 kv tidb的run脚本里面果然有老的pd的信息，db是混合了新老pd，kv是只有老的pd信息。当时PD扩容缩容操作没有涉及DB和KV的run脚本修改。后续应该如何处理？

谢谢

[zhenjiaogao]

您那里提到的含有已下线的 pd 的 run 脚本，方便按照下面的形式提供下吗？这里再看下：

1、TiDB Server

run 脚本内容：
xxxx

2、TiKV Server

run 脚本内容：
xxxx

3、PD Server

run 脚本内容：
xxxx

[Hacker_Lc1rnkne]

你好 信息在下面，谢谢

@zhenjiaogao-PingCAP

1、TiDB Server

run 脚本内容：
set -e

ulimit -n 1000000

# WARNING: This file was auto-generated. Do not edit!
#          All your edit might be overwritten!
DEPLOY_DIR=/data/tidb/deploy

cd "${DEPLOY_DIR}" || exit 1

export TZ=Asia/Shanghai

exec bin/tidb-server \
    -P 4000 \
    --status="10080" \
    --advertise-address="10.10.48.193" \
    --path="10.10.48.98:2379,10.10.48.119:2379,10.10.48.127:2379,10.10.48.193:2379,10.10.48.194:2379,10.10.48.195:2379" \
    --config=conf/tidb.toml \
    --enable-binlog \
    --log-slow-query="/data/tidb/deploy/log/tidb_slow_query.log" \
    --log-file="/data/tidb/deploy/log/tidb.log" 2>> "/data/tidb/deploy/log/tidb_stderr.log"

2、TiKV Server

run 脚本内容：
set -e
ulimit -n 1000000

# WARNING: This file was auto-generated. Do not edit!
#          All your edit might be overwritten!
cd "/data1/deploy" || exit 1

export RUST_BACKTRACE=1

export TZ=${TZ:-/etc/localtime}

echo -n 'sync ... '
stat=$(time sync)
echo ok
echo $stat

echo $$ > "status/tikv.pid"

exec bin/tikv-server \
    --addr "0.0.0.0:20171" \
    --advertise-addr "10.10.48.190:20171" \
    --status-addr "10.10.48.190:20181" \
    --pd "10.10.48.98:2379,10.10.48.119:2379,10.10.48.127:2379" \
    --data-dir "/data1/deploy/data" \
    --config conf/tikv.toml \
    --log-file "/data1/deploy/log/tikv.log" 2>> "/data1/deploy/log/tikv_stderr.log"

3、PD Server

run 脚本内容：
set -e
ulimit -n 1000000

# WARNING: This file was auto-generated. Do not edit!
#          All your edit might be overwritten!
DEPLOY_DIR=/data/tidb/deploy

cd "${DEPLOY_DIR}" || exit 1



exec bin/pd-server \
    --name="pd_tidbpd193" \
    --client-urls="http://10.10.48.193:2379" \
    --advertise-client-urls="http://10.10.48.193:2379" \
    --peer-urls="http://10.10.48.193:2380" \
    --advertise-peer-urls="http://10.10.48.193:2380" \
    --data-dir="/data/tidb/deploy/data.pd" \
    --initial-cluster="pd_tidbpd193=http://10.10.48.193:2380,pd_tidbpd194=http://10.10.48.194:2380,pd_tidbpd195=http://10.10.48.195:2380" \
    --config=conf/pd.toml \
    --log-file="/data/tidb/deploy/log/pd.log" 2>> "/data/tidb/deploy/log/pd_stderr.log"

[zhenjiaogao]

好的，收到。

另外，再确认下 PD 的缩容步骤：
1、pd-ctl delete member pd119
2、ansible-playbook stop.yaml -l pd119
3、编辑 inventory 文件将 pd119 的相关内容均注释掉
4、ansible-playbook deploy.yml

TiKV 以及 TiDB 的 run 脚本遗留 pd119 的信息，可能是缩容 pd119 的步骤存在异常。

[Hacker_Lc1rnkne]

我追溯了一下操作历史 只做了 ansible-playbook deploy.yml --tags=pd ，那这样说的话当时应该对整个环节都做deploy吧？ ansible-playbook deploy.yml，后续的话怎么处理？

560 ansible-playbook -i hosts.ini create_users.yml -l 10.10.48.193,10.10.48.194,10.10.48.195 -u root -k
561 ansible-playbook -i hosts.ini deploy_ntp.yml -u tidb -b
562 ansible-playbook bootstrap.yml -l 10.10.48.193,10.10.48.194,10.10.48.195
570 vi roles/machine_benchmark/tasks/fio_randread.yml
571 ansible-playbook deploy.yml -l 10.10.48.193,10.10.48.194,10.10.48.195
572 ansible-playbook start.yml -l 10.10.48.193,10.10.48.194,10.10.48.195
573 /home/tidb/tidb-ansible/resources/bin/pd-ctl -i -u “http://10.10.48.98:2379”
574 /home/tidb/tidb-ansible/resources/bin/pd-ctl -i -u “http://10.10.48.193:2379”
576 vi inventory.ini
577 ansible-playbook deploy.yml --tags=pd
578 vi inventory.ini
579 ansible-playbook deploy.yml --tags=pd
580 vi inventory.ini
581 ansible-playbook stop.yml -l 10.10.48.118,10.10.48.125
582 vi inventory.ini
583 ansible-playbook rolling_update_monitor.yml --tags=prometheus

[zhenjiaogao]

1、通过之前的历史步骤基本可以确认是缩容 pd 的操作步骤异常导致的上述问题

2、理论上，在确认 inventory 文件中无 pd119 相关信息，并且 tidb 集群中所有组件的 binary 文件版本没有发生过变化（inventory 文件中 tidb_version 参数）的情况下，可以执行 ansible-playbook deploy.yml ,来统一更新集群配置。

以上请评估~

注意：

• 操作建议在业务低峰期进行。
• 建议使用 TiUP 来运维管理集群。

[Hacker_Lc1rnkne]

非常感谢~

[zhenjiaogao]