嗯嗯，这个方式固然可行，但是从监控和运维角度来说风险还是蛮大的。比如你去年用CDC搭了一套异地灾备，跑了一年多忽然要做灾备切换，然后在TiDB备集群上一看少了很多表，那这些表是DBA主动忽略的，还是在这运行的一年时间里，应用程序或者研发自己建上去的，很难说清楚，而且这个提示信息只显示一次就没了，cdc的日志也可能被清理掉。 如果有API接口或者表视图什么的能查询或者监控这些被discard的表，那其实是能够在事前避免掉的

直接在上游查询没有主键和唯一索引的表，无法区分是我在创建changefeed时主动忽略的表，还是changefeed运行起来后，它自动忽略的表

谢谢，我试一下这个参数

谢谢，关于过滤rules这里，想请教一下，我配置的是*.*，想连同mysql库一起复制到下游cdc，但是我发现在mysql库里面新建表，或者create user，都无法同步到下游，这里是什么原因呢? [iwEdAqNqcGcDAQTRA8AF0QUABrBncT1XGpZFcwXGlFQbspoAB9IIc14bCAAJomltCgAL0gACWCE.jpg_720x720q90] cdc日志里提示create table taa被discard了 [iwEdAqNqcGcDAQTRBI4F0QNqBrBxsIxnrhe3_gXGlFUPiO4AB9IIc14bCAAJomltCg…

Toad for Oracle

delete from t1 where xxx in (select xxx from t2); commit; 这是个很常见的半连接，然而t2表并没有xxx这个字段… 有兴趣的可以去prod试一次，倍儿刺激~

5.6还有一大片…

执行SQL语句时出现报错：1105 - Out Of Memory Quota 解决方案：可以在session级别设置tidb_mem_quota_query到足够大，例如： set tidb_mem_quota_query=8589934592;

嗯，我们SQL要求直接走审核平台留痕，没有用pt-osc或者gh-ost这类工具

一次上线发版，由于表很大modify column执行太久，最终abort操作而发版没成功。老板问原因，研发同学的回答是：DBA未严格审核SQL。 从此，我秉着工作认真严谨的态度，以最高级别最要求的严格审核该研发战队的SQL代码，任何不符合规范任何存在不确定因素和风险点的代码全部都不予通过和上线

开个宠物店

认识了一些圈内的朋友

1、并发量超预期，需要重新评估业务量，看是否需要在应用侧进行限流 2、问题SQL需要进一步分析，开是否存在优化空间 3、根据实际情况，对OLAP库进行扩容

跳槽确实是升职加薪最快的途径

完全的数据库自治

未来数据库自治以后，DBA的技能树也要跟着进阶，否则会被淘汰

回老家了哦

问题：恶意刷积分是否会受到惩罚？ 答案：是的

我没有说性能损耗。K8s很多场景会使用网络存储和共享盘这种，比如云平台上，它和使用本地PCIE闪存卡比IO性能是有差距的。当然K8s上TiKV也可以使用本地盘，但这样的话灵活性就会打折，不如直接跑裸金属