使用 TDSQL Boundless 的注意事项？
用户平时需要关注实例的哪些监控指标？
警告：
为保障数据库实例的稳定运行，TDSQL Boundless 提供了存储空间保护机制。当节点存储使用率达到指定阈值时，系统将自动启用只读保护，避免因存储耗尽导致实例异常。为了避免未及时关注硬盘（存储空间）的变化引起实例只读锁定，请您设置磁盘利用率指标告警，操作请参考 设置告警策略。 触发只读保护机制：当任一节点的存储空间使用率超过系统设定的阈值（默认值91%）时，该节点将自动进入只读模式。
只读保护模式影响：写入操作（如 INSERT, UPDATE 以及 DELETE）将被拒绝，但数据查询和清理操作（如 DROP, TRUNCATE）不受影响，其他未触发阈值的节点数据读写操作不受影响。注意，3副本场景下，若2个或以上副本进入只读模式，整个实例将进入只读模式。如果无法通过 DROP 或者 TRUNCATE 快速删除数据的情况下，可以尝试进行磁盘扩容以扩容脱离阈值进行 DELETE 数据删除。您也可以联系 腾讯云技术支持协助评估并临时修改阈值清理数据。 只读模式自动恢复：当您通过扩容或清理数据等方式，使空间使用率下降至系统设定的阈值以下时，该节点将自动恢复为可读写模式。
关于 DELETE：由于在 LSM Tree 引擎中，DELETE 是以“删除信息”的方式被追加写入，因此也被视为一种写入，且并不会立刻使得数据减少。在进入只读模式的情况下，用户也无法进行 DELETE 操作。而 DROP 和 TRUNCATE 则不受影响。
CPU 利用率、内存利用率、磁盘空间利用率。您可以根据实际情况 设置告警策略，当收到告警，可采取相应措施消除告警。 哪些内容会占用实例节点的磁盘空间？
警告：
为了避免您的数据库"被锁"，请务必关注磁盘空间告警！
TDSQL Boundless 的存储空间保护机制会在节点磁盘使用量超过系统设定的阈值（默认值91%）时自动进入只读模式，此时您的业务写入（INSERT/UPDATE/DELETE）将直接报错，直到空间降回阈值以下才能恢复。请一定要设置磁盘利用率告警（建议75% ~ 80%），给自己留出处理时间。
节点的磁盘已用空间包括数据文件空间、日志文件空间与其他：
数据文件：用户正常写入的数据文件（不包括备份数据），对应的节点监控指标为数据文件空间占用量；
日志文件：数据库实例正常运行所需的 WAL 日志文件，即 Redo 日志文件，对应的节点监控指标为日志文件空间占用量；
其他：数据库引擎的二进制可执行文件等
TDSQL Boundless 支持几种表类型？是否有单表、广播表、分区表？
在 TDSQL Boundless 中，目前主要支持普通表，包括带分区和不带分区两种。
对于带分区的表，不同分区的数据可以分散到不同节点上；
对于不带分区的表，如果数据量较大，复制组（Replication Group，RG）也会分裂，并均衡分散到各个节点上。
TDSQL Boundless 也支持广播表：建表时可定义某表在所有节点进行复制。
TDSQL Boundless 是否提供了读写分离能力？
读写分离通常用于解决以下两个问题：
1. 在传统的主从架构中，通过读写分离可以充分利用备库的资源。
2. 针对具有明显 AP（可用性优先）和 TP（一致性优先）业务场景的应用，读写分离可以避免两者之间的相互影响。
然而，TDSQL Boundless 的架构与传统的主从架构（如 InnoDB）有所不同。在 TDSQL Boundless 中，数据均匀分布在所有节点上，因此每个节点的 CPU、IO 等资源都可以得到充分利用，无需依赖读写分离来利用备库资源。
对于一些需要将 AP 读取 SQL 与 TP 场景进行隔离的情况，我们计划在后续版本中提供相应的支持。
TDSQL Boundless 目前的灾备能力支持情况如何？
TDSQL Boundless 具备多样化的服务高可用技术，包括实例内的多副本容灾和实例间的物理备库容灾。
实例内的多副本容灾
同机房三副本：同机房内三副本组成一个实例，能够防范少数派节点故障，无法防范机房级故障。
同城三机房三副本：面向具备一个城市三个机房的场景。同城三个机房组成一个实例（每个机房是一个可用区），机房间网络延迟一般在0.5 ~ 2ms之间。能够防范少数派节点故障、单机房故障，无法防范城市级故障。
实例间的物理备库容灾：当前已具备同城灾备和跨城灾备能力。在两个完全独立的实例之间提供数据同步以及切换主备关系的能力。当主库出现计划内外的不可用情况时，备库可以接管服务。
注意：
1. 如果应用程序是处理关键业务，对业务连续性有很高的要求，那么应用程序应该具备与数据库相同的容灾等级。这是因为即使数据库能够在发生故障时快速恢复，如果应用程序本身没有相应的容灾能力，那么业务仍然会受到影响。
2. 实例间的物理备库容灾，选择该容灾方案需要注意：主备实例之间的数据同步是准实时的。有两种切换模式：Switchover（计划内切换），Failover（故障切换）。Switchover 可以做到无损，Failover 是有损的（故障强切场景，通常可能会出现5秒内的数据损失，取决于备实例同步实际落后的情况）。
TDSQL Boundless 中自增字段为何会出现跳跃现象？
在 TDSQL Boundless 数据库中，自增字段暂时只保证全局唯一，不保证全局自增。
为了提高自增字段值的分配效率，TDSQL Boundless 采用了分片缓存机制。例如，如果有三个计算节点，它们可能会分别缓存一段连续的自增值：
A 节点缓存自增范围1 - 100；
B 节点缓存自增范围101 - 200；
C 节点缓存自增范围201 - 300。
当 A 节点的缓存值用尽后，它将获取下一个可用的自增范围，比如301 - 400。这种机制确保了即使在分布式环境下，自增字段的值也能快速分配，但同时也可能导致自增值出现跳跃，因为不同节点之间的缓存值是不连续的。
TDSQL Boundless 是否支持 JSON？
JSON 是支持的，也支持 JSON_ARRAYAGG，JSON_OBJECTAGG 两种聚合函数。（目前跟 MySQL 一致）。
TDSQL Boundless 是否支持外键和全局索引？
TDStore 不支持外键和全局索引。如果需要确认迁移实例是否涉及这些功能，请联系技术支持获取扫描工具进行判断。
如果事务最终 Rollback，已经复制到 Follower 的日志会怎么处理？
在 Raft 协议中，如果一个事务最终需要回滚（rollback），已经复制到 follower 节点的日志条目将不会被应用到状态机中，也就是说，它们不会影响到底层的数据存储。这是因为这些日志条目被视为 "未提交"。
Raft 协议通过以下机制来确保 "未提交" 的日志条目不会被错误地应用：
维护 commitIndex：Raft 协议使用一个名为 commitIndex 的变量来跟踪已提交日志条目的最大索引。只有当日志条目的索引大于 commitIndex 时，它才会被认为是已提交的。如果事务回滚，commitIndex 将保持不变，这样就防止了 "未提交" 的日志条目被应用到状态机。
日志截断：在某些情况下，例如发生故障切换时，新选举出的 leader 节点可能需要截断其日志以确保集群的一致性。新 leader 节点会删除日志中的 "未提交" 条目，并将这些更改同步到 follower 节点。这样，与回滚事务相关的日志条目就会从整个集群中移除。
通过这些机制，Raft 协议保证了即使在事务回滚的情况下，也能维护集群的数据一致性和完整性。
系统提示"实例版本校验错误；请升级内核至最新版后重试"，需要怎么做？
TDSQL Boundless 内核在不断迭代升级中，如果您遇到上述系统提示，请联系 腾讯云技术支持 为您升级引擎内核。