你提到的命令tc qdisc add dev ens192 root netem delay 5000ms应该在从库上执行。这个命令使用的是traffic control（tc）工具，它在从库的网络接口ens192上添加了一个名为netem的队列纪律，用于模拟5000毫秒（5秒）的网络延迟。

当你在从库上设置了这种延迟后，从库的I/O线程（即负责从主库拉取并应用二进制日志的线程）在拉取和应用主库的更新时，会遇到这个延迟。理论上讲，这将导致从库的复制延迟。

但是，如果你没有在show slave status的结果中看到I/O线程的延迟，可能的原因有以下几点：

1. 延迟尚未累积：如果I/O线程在你设置延迟之前已经同步了所有数据，那么它可能在等待新的数据，此时延迟设置可能还未发挥作用。

2. 网络包的延迟应用：netem delay是针对网络包的，它可能不会立即影响到MySQL正在处理的当前网络包，只有当新的网络包通过该接口时，才会应用延迟。

3. MySQL复制机制：MySQL的复制是基于事件的，它可能在完成一个事件的处理后才去拉取新的事件，因此即使有网络延迟，也可能在I/O线程的状态中不立刻体现。

4. 从库的读取超前：如果从库I/O线程的读取位置已经超前于设置延迟的时间点，那么延迟的效果不会立即体现在show slave status的输出中。

5. 监控时间点：可能在你观察show slave status时，I/O线程正好没有在进行网络传输，因此没有体现出延迟。

为了观察到延迟的效果，你可以尝试以下步骤：

• 确保在设置延迟后，主库有新的写操作（如INSERT、UPDATE等）。
• 等待足够长的时间，让延迟累积，然后观察show slave status的输出，关注Last_IO_Errno和Last_IO_Error，以及Seconds_Behind_Master字段。
• 尝试在主库上执行一些操作，然后等待从库的I/O线程去拉取这些更新，观察延迟是否产生效果。

如果以上操作仍无法观察到延迟，可能需要进一步检查网络配置和从库的复制状态，确保复制环境正确配置且网络延迟正确设置。