生产环境全链路压测建设历程 26：FAQ 之 压测结束阶段的相关问题

数据清理采用的手段？全链路各个环节的数据通过后台清理还是业务触发删除？影响和表现哪种更好？

1.只要有影子表、影子库的用户名、密码，就可以编写对应的 shell 脚本来进行相关操作。

1. 一般是通过脚本来后台删除是最好的，脚本经过编写、测试、review。

2. 业务触发删除不太推荐使用。 占用业务服务器的运行资源，效率也低。

如 Cassandra 等 nosql 数据库的数据清理如何解决墓碑问题？

Java 的系统，基本上都是通过 JDBC 的协议来访问 Cassandra 等 NoSQL 的数据库，JDBC 的协议，探针都支持流量隔离写入到影子区域。

所以本身压测数据的影子表和真实数据是隔离开的。

不需要用 delete(upsert)的形式去删除压测数据，而是直接 drop table，然后重建。

表空间及数据文件大小，以及对索引的影响，需要重建吗？

本身压测数据的影子表和真实数据是隔离开的。基本不需要做这块事情了。 但如果是 MySQL，建议在清理数据的时候，尽管是使用 truncate 或者 drop table，也要 sleep 2-3 秒左右，不要对 innodb buffer 有太大的冲击。 Oracle、Linux OS 和其他存储也是同理。

执行和清理阶段，遇到的准备阶段未考虑到的问题？

1.在生产压测期间，一般会关闭数据库的自动切换配置。避免因为流量对数据库的压力太大，或者是自动切换的阈值过低，或者是网络容量等等瓶颈点，触发了数据库的主备自动切换。

2.数据库如 MySQL 的一些临时预案的提前执行， 如 syncbinlog, innodbflushlogat_trx_commit 从双 1 改成双 0（刷盘变成刷内存）等

3.一般会是先做好单链路、入口的生产压测，确保服务本身的 SLA，然后再来做全链路的压测验证。（D 快递、S 快递都是这样玩了，各个业务线自己先玩好，然后每个月底组织一波全链路压测验收，根据压测结果进行对应的优化）。