使用 TDSQL Boundless 的注意事项？
用户平时需要关注实例的哪些监控指标？
其中，磁盘利用率尤为关键。TDSQL Boundless 为此提供了数据保护空间机制：
数据库实例磁盘写到100%后，数据库无法写入日志、无法写入数据文件、无法创建临时文件，连 DROP/TRUNCATE 这类清理操作也会因需要写日志而失败。为此，TDSQL Boundless 在每个对等节点预留了一份“数据保护空间”：当对等节点的存储使用率触及阈值时，节点自动进入为只读模式，在磁盘彻底写满前为运维保留清理和扩容的操作窗口。
触发只读保护机制：当任一节点的存储空间使用率超过系统设定的阈值时，该节点将自动进入只读模式。
只读保护模式影响：写入操作（如 INSERT/UPDATE）将被拒绝，但数据查询和清理操作（如 DROP/TRUNCATE）不受影响，其他未触发阈值的节点数据读写操作不受影响。注意，3副本场景下，若2个或以上副本进入只读模式，整个实例将进入只读模式。
只读模式自动恢复：当您通过扩容或清理数据等方式，使空间使用率下降至系统设定的阈值以下时，该节点将自动恢复为可读写模式。
说明：
数据保护空间的默认值大小随着实例的硬盘类型不同而存在差异：
本地盘实例：默认值为
min{节点磁盘容量 × 8%, 200 GB}，本地 SSD 硬盘实例触发节点只读从而需要扩容时若资源不足，需要在节点间进行数据搬迁，耗时分钟至小时级，需要预留出足够的时间；云盘实例：默认值为
max{节点磁盘容量 × 1%, 1 GB}，增强型 SSD 云硬盘支持秒级在线扩容，触发节点只读后，即时在线扩容云盘容量即可恢复，无需大额预留空间。数据保护空间的设置对实例生效。例如，实例 A 的对等节点的磁盘100GB，数据保护空间16GB，即实例 A 的每个对等节点都预留出16GB空间。当实例 A 的节点已用空间达到84GB时触发节点只读，此时该节点的写入操作被拒，但 DROP/TRUNCATE 仍可执行，您可借这16GB完成清理或者扩容。
注意：
数据保护空间自内核版本 V21.6.4.0 起正式支持，内核版本低于 V21.6.4.0 时该功能为公测功能，数据保护空间展示可能不准确。
哪些内容会占用实例节点的磁盘空间？
警告：
为了避免您的数据库"被锁"，请务必关注磁盘空间告警！
TDSQL Boundless 的存储空间保护机制会在节点磁盘使用量超过系统设定的阈值时自动进入只读模式，此时业务写入（INSERT、UPDATE、DELETE）将直接报错，直到空间降回阈值以下才能恢复。云盘和本地盘的默认阈值不同，请按磁盘类型分别设置磁盘利用率告警，告警阈值建议比只读阈值低10 - 15个百分点，给自己留出处理时间。关于默认阈值的详细说明，请参见 数据保护空间。
节点的磁盘已用空间包括数据文件空间、日志文件空间与其他：
数据文件：用户正常写入的数据文件（不包括备份数据），对应的节点监控指标为数据文件空间占用量。
日志文件：数据库实例正常运行所需的 WAL 日志文件，即 Redo 日志文件，对应的节点监控指标为日志文件空间占用量。
其他：数据库引擎的二进制可执行文件等。
实例已进入只读模式，应该如何恢复？
当节点存储空间使用率超过只读阈值后，您可以通过以下方式恢复读写。推荐优先选择磁盘扩容，这是最安全且对业务影响最小的方案。
磁盘扩容（推荐）：在控制台为实例的存储节点增加磁盘容量，使空间使用率回落到阈值以下。扩容过程无需重启实例，只读状态在扩容完成后自动解除。
清理可回收空间：在扩容生效前，您可以先清理以下非业务数据快速释放部分空间：在清理数据前，请务必确认：待清理的数据已有有效备份，清理后不可恢复。待清理的表已确认不再被业务使用，避免误删线上数据。
DELETE 操作在只读模式下不可用（在 LSM Tree 引擎中 DELETE 本质上是追加写入，同样会触发写入限制），只有 DROP TABLE 和 TRUNCATE TABLE 可以正常执行。清理不再需要的日志文件。
删除临时表或已确认不再使用的历史数据表。
对于已备份且确认可删除的冷数据，可执行
DROP TABLE 或 TRUNCATE TABLE 释放空间。调整数据保护空间：实例/节点已进入只读时，可临时调小保护空间紧急恢复服务，但长期仍需合理规划存储容量，详细请参见 调整数据保护空间。
无论采用以上哪种方式，只要节点空间使用率回落到阈值以下，节点会自动恢复为可读写模式，无需人工介入解锁。
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 协议保证了即使在事务回滚的情况下，也能维护集群的数据一致性和完整性。
