通过PCTP考试

TiDB Lightning 和 Dumpling 支持导入和导出压缩格式文件。

已报名，期待精彩的演讲！ [302095ba9521656c5597c7a1951dc6a]

感谢分享，准备好后先内部试讲一次

TP和AP可以鱼和熊掌兼得，计算和存储可以灵活水平扩展。用过会感叹：恨不相逢选型时！

读操作在缓存数据同时，对于缓存设置一个 lease有效期.在 lease 过期之前，写操作无法对数据执行修改操作。所以会导致写入延迟。延迟的时间受全局变量tidb_table_cache_lease控制。 缓存表首次加载从TiKV中读取，后续的读写应该都是访问内存中的缓存数据。

首先，要保持学习的动力。有数据表明，一个持续学习的人，就几乎战胜了80%的同龄人。 然后，作为技术人，最主要的是提升自身的硬核技术技能，同时在学习和工作过程中，也要注重提升相关的软能力，包括写作、分享、合作等。比较擅长管理的同学，提升自己的管理能力当然更好。 最后，技术人不能只专注于技术领域，其他相关领域的知识也要去学习和了解。通过学习，让自己具备技术和行业发展趋势的判断能力，这样可以最大程度的确保自己的学习方向不会出现大的偏差。如果学习的方向是错的，那与其南辕北辙，还不如原地躺平。 时间会奖励不断学习的人。与诸位TiDBer共勉~

大佬可不敢当，我们互相学习

你的说法是对的，这个的确不能叫抗城市级别的灾难。应该是如你所说，A城一套集群，B城一套集群，两套集群通过 ticdc 同步数据。这样在A城的两个数据中心都挂了的情况下，数据库的访问流量能切到B城应急，数据库服务还是处于可用状态。

1、两地三中心架构中，通过异步复制实现异地灾备。在城市A的两个数据中心都不可用的情况下，实现抗城市级的灾难。 2、采用tidb binlog或者ticdc也可以实现异步复制，但需要在A城和B城各部署一套tidb集群，而且数据同步需要通过额外的同步任务完成，稳定性不如数据库原生的raft异步复制。 个人的一点学习认识，供参考。

看到你的标题，结合我之前看过的内容，我感觉内存悲观锁原理浅析与实践这篇文章里应该有你需要的内容。很高兴能帮你节省了搜索的时间，也要谢谢文章的作者jilf，让我们快速学习到了内存悲观锁的知识。

正常运行状态 [image]

也可以参考一下这篇 内存悲观锁原理浅析与实践

热烈欢迎

1、region是KV Map中通过range方案划分出来的一个左闭右开区间，和SQL中的table没有什么关系。默认3副本的region数据持久化在三个KV节点的RocksDB中。 2、table是逻辑上的概念，所有的表数据都通过Key-Value的格式存储在RocksDB中。所有逻辑概念上的table都通过KV节点的2个RocksDB实例实现分布式ACID事务。一个KV节点上对应了4个CF，raft log db（Default CF），kvdb(default、lock、write)。 个人的理解，供参考。

SELECT COUNT(1) FROM ( SELECT m.* FROM ( SELECT id, send_user_id, receive_user_id, send_time, receive_time, content, customer_id, system_id, receive_user_name, send_user_name FROM tbl_message WHERE send_time >= 1651334400 AND send_time < 1653840000 ORDER BY send_time DESC, id DESC ) AS m ORDER BY m.…

[photoframe] 推荐定制相框和鼠标，想要的同学给我点赞~

赞，有创意，大风起兮KV飞扬

AUTO_ID_CACHE的默认值30000，TiDB 保证AUTO_INCREMENT自增值在单台服务器上单调递增。集群中的多个tidb实例， 实例 A 可能会缓存 [1,30000] 的自增 ID，而实例 B 则可能缓存 [30001,60000] 的自增 ID。在不同tidb实例上执行sql语句，那么自增列的值可能会出现跳跃。 具体参见 AUTO_INCREMENT