【在数据库运维时,DBA 们会做什么事情来提高数据库安全性?如权限分发、灾备等】
数据库的最大作用,一个是存数据,一个是访问数据。
针对数据库的安全,也主要从这两个方面来做措施:
1、数据库的数据本身的安全。
加密存储、数据脱敏
备份(定期全备+实时增量备份)
高可用架构(主备、分布式集群,单集群跨机房部署、两地三中心、三地五中心等)
等等。
2、数据访问上的安全。
访问控制、访问传输加密等
账号最小权限管理、定期更改口令、强密码等
审计
等等。
【哪些是你常用到的数据库安全特性?如访问控制、传输加密等】
大部分都有用到。
统计信息的管理,一般是三板斧管理:
整个集群全局影响/自动收集管理:
1、指定收集时间段,通常选择在集群的业务空闲时间内执行。
2、指定表变更行数的比例,默认是一个表有50%的行发生了变更就会触发,按需调大或调小。
上面的操作集群会自动在后台执行,默认会有限流保护机制,消耗资源低,不影响正常业务,大部分情况下集群无感知。
单个表控制/主动介入管理:
3、主动收集,采用手动或脚本定时执行analyze更新统计信息。
该方式由于是管理员执行的SQL语句,不再是集群自身后台命令,所以不会有限流保护机制,但是默认的收集参数配置也比较低,通常对集群也不会有什么影响,大部分情况下可以采用默认…
期待 社区架构师李老师的精彩分享

如果允许,在v7.5.5版本强烈推荐使用ticdc,使用pump+drainer的方式弊端很多,官方也不建议使用,这个方式在高本版已经弃用。
owner的切换总体上不会影响同步任务的后续管理的,请问是遇到了什么问题
【你看过哪些让你眼前一亮的架构案例或设计思路?】
HTAP 行列混合架构,还支持Raft实时更新和数据强一致。
【所在行业的场景对系统架构有哪些要求?】
对于所在行业,甚至是大部分行业,稳定性压倒一切
【你认为 TiDB 是否能让您现有的架构在满足业务需求的同时更加简洁、高效和优化?】
相信可以
期待各位大佬的精彩分享~

1、这里是打印出代码的报错位置的路径,不是说要访问
github.com。
2、根据楼主贴出来的报错信息,大概率是PD节点(集群的大脑、调度节点)没有正常起来,导致后面无法部署集群。
[2025/07/16 17:56:14.193 +08:00] [FATAL] [main.go:120] [“run server failed”] [error=“[PD:server:ErrCancelStartEtcd]etcd start canceled”] [stack=“main.main\n\t/home/jenkins/agent/workspace/build-common/go/s…
tikv机器出现内存告警问题,通常与几个因素有关:
1、 一台机器是否有混合情况出现?
tikv 和 tidb tipd 是否混部
单机部署几个tikv
tikv机器上是否还有其他高消耗内存的进程
如果出现混部的情况,要尽量避免。
2、确认tikv配置情况,这里主要就是 tikv 的 block-cache 配置了。
这个可以参考官方文档的推荐值。
3、 基础环境配置环境不当,比如未正确关闭 内存大页 THP 等。
如果是这个情况,请关闭内存大页。
楼主试着都分析排查下。
应该是指其他副本的状态。
默认三副本的数据,每个副本之间互相称为彼此的peer
看配置图是每个节点配了4GB的block cache,因为还没达到最大值,所以随着访问量越来越大,它使用的cache 也会不断增加的,直到最后稳定在4GB左右
【你在毕业前学的是什么专业或研究方向】
计算机
【如果时光倒流,如果你还想从事数据库相关工作,你会选择读什么专业】
不变
【现在还是学习、从事计算机(数据库)行业的好年代么】
是
【其他想分享的话】
养成良好的学习生活习惯,追求卓越
1、TiDB的表定义里面明确指定了【NOT NULL】了,所以值肯定不能为NULL了,否则就违反了表的定义要求了,tidb这里的做法更加严谨、可靠,是符合预期的,应该推荐这个用法。
2、如果想要在TiDB v8.5.1里的表插入date_add为NULL值,那么需要楼主修改表结构的定义,把date_add字段的【NOT NULL】去掉,即改为:date_add timestamp DEFAULT CURRENT_TIMESTAMP 。
具体可以参考如下:
3、5.7.54确实如楼主所言,即便设置了NOT NULL,还是可以插入NULL值。(不按照预期来)
mysql> select v…
按照使用经验来说,这个Tombstone Stores是表示历史上 变为tombstone的tikv节点数量。当年我们首次使用的时候也和原厂工程师做过沟通,这是个合理正常的数值,方便查看,用户可以不用关注这个点。
如果说有什么“不合理”的点,那就是不应该标注为“红色”,避免以为是有问题,其实当前集群是正常的,可能标记为灰色更符合大家的习惯。
根据楼主贴的监控图信息,是store-1 这个tikv节点出现了访问延迟过高,单点瓶颈问题导致cop 任务(在存储层扫描读取数据的过程)出现了慢的现象。
先确认store-1对应的ip和节点,然后重点分析下它:
1、是否有热点问题
2、是否节点当时过于繁忙导致的抖动问题
3、根据该节点的tikv日志,分析当时有无其他异常信息,结合集群当时的现状深入分析