ScyllaDB nodetool scrub 完全指南识别与修复损坏 SSTable 的四种模式与隔离机制【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbnodetool scrub是 ScyllaDB 提供的用于识别并修复损坏 SSTable 的运维命令它能够移除错误数据、清理已超过表gc_grace周期的 tombstone 行并修复乱序的 row 与 partition。本文以 ScyllaDB 官方操作文档为骨架结合compaction/、api/、sstables/目录下的真实实现与test/中的测试用例系统讲解 scrub 的全部参数、四种 scrub 模式、三种 quarantine 模式以及两套清除损坏 SSTable的完整实操流程。读完本文你将能根据不同的损坏类型选择正确的 scrub 策略并安全地隔离、保留或删除损坏的 SSTable。scrub 能做什么命令概述scrub 的核心工作是对 SSTable 执行反序列化 重新序列化deserialize reserialize在此过程中识别并尽可能修复以下三类问题损坏的数据corrupted data由于磁盘故障、异常断电等原因导致的数据字节错误已过期 tombstone超过表gc_grace周期、可以安全清除的 tombstone 行乱序的 row / partitionSSTable 内行或分区顺序违反排序约束的情况。需要注意的是正如官方文档所指出的并非所有类型的损坏都能被 scrub 修复或跳过。scrub 针对的是数据层面的结构性问题对于超出其能力范围的损坏需要结合下面介绍的 quarantine 机制来隔离和处置。在 ScyllaDB 中scrub 本质上是一次特殊的 compactioncompaction_type::Scrub。从源码看scrub 的入口链路为nodetool scrub→ REST API/storage_service/keyspace_scrub/{keyspace}见 api/storage_service.cc 中的ss::scrub处理器与 api/api-doc/storage_service.json 中的接口定义→ 创建scrub_sstables_compaction_task_impl任务 → 由compaction/compaction.cc中的scrub_compaction类实际执行。scrub 结束后的状态码定义在 api/scrub_status.hhsuccessful 0、aborted、validation_errors其中unable_to_cancel在 Scylla 中未使用仅为了与 nodetool API 保持兼容。命令语法与完整参数说明scrub 的完整命令语法如下nodetool [(-h host | --host host)] [(-p port | --port port)] [(-pp | --print-port)] [(-pw password | --password password)] [(-pwf passwordFilePath | --password-file passwordFilePath)] [(-ns | --no-snapshot)] [(-s | --skip-corrupted)] [(-m scrub_mode | --mode scrub_mode)] [(-q quarantine_mode | --quarantine-mode quarantine_mode)] [--drop-unfixable-sstables] [--] keyspace [table...] 支持的 scrub 模式VALIDATE、ABORT、SKIP、SEGREGATE 支持的 quarantine 模式INCLUDE、EXCLUDE、ONLY参数表参数说明-ns/--no-snapshotscrub 开始前不拍摄所有被 scrub 表的快照默认false即默认会先拍快照。-s/--skip-corrupted跳过损坏的 row 或 partition即使是对 counter 表进行 scrub 时也生效。已弃用请改用--mode默认false-m scrub_mode/--mode scrub_mode如何处理损坏数据取值为VALIDATE\|ABORT\|SKIP\|SEGREGATE之一默认VALIDATE会覆盖--skip-corrupted。-q quarantine_mode/--quarantine-mode quarantine_mode如何处理已被隔离的 SSTable取值为INCLUDE\|EXCLUDE\|ONLY之一默认INCLUDE。--drop-unfixable-sstables丢弃无法修复的 SSTable而不是中止整个 scrub仅在与--modeSEGREGATE组合时有效。--quarantine-invalid-sstables true\|false损坏的 SSTable 是否应被隔离默认true仅在与--modeVALIDATE组合时有效。--用于将命令行选项与参数列表分隔开当参数可能被误认为命令行选项时很有用。keyspace要 scrub 的 keyspace。[table...]可选。一个或多个要 scrub 的表。默认情况下keyspace 中的所有表都会被 scrub。参数背后的实现逻辑以上参数在 REST API 层被逐一解析逻辑集中在 api/storage_service.cc 的parse_scrub_options()函数中-m/--mode与-s/--skip-corrupted的优先级如果未显式传入scrub_mode则回退读取skip_corrupted参数为true时模式被置为SKIP如果显式传入了scrub_mode则完全覆盖skip_corrupted。这与文档中--mode会覆盖--skip-corrupted的说明一致。默认快照只有当disable_snapshot为false且确实有表需要 scrub 时才会生成快照标签pre-scrub-时间戳随后在ss::scrub处理器中通过db::snapshot_optionsskip_flush false即不跳过 flush执行快照。这解释了为什么默认情况下 scrub 会先拍快照。参数校验drop_unfixable_sstables在非SEGREGATE模式下传入会抛出bad_param_exceptiononly valid when scrub_mode is SEGREGATEquarantine_invalid_sstables在非VALIDATE模式下传入同样会报错only valid when scrub_mode is VALIDATE。这些约束与命令语法中的标注完全对应。quarantine 模式解析quarantine_mode默认值为INCLUDEEXCLUDE/ONLY分别对应枚举compaction_type_options::scrub::quarantine_mode的exclude/only见 compaction/compaction_descriptor.hh。四种 scrub 模式详解scrub 的四种模式定义在 compaction/compaction_descriptor.hh 的compaction_type_options::scrub::mode枚举中其行为差异如下Scrub 模式行为说明VALIDATE只读模式在 scrub 过程中报告发现的所有损坏但不修复它们。同时会通过校验存储的 digest若存在来验证组件完整性。默认情况下损坏的 SSTable 会被移动到 quarantine 子目录从而避免参与 compaction。默认模式ABORT出现第一个校验错误时立即中止 scrub。SKIP跳过损坏的 row 或 partition等同于旧版--skip-corrupted选项。警告该模式可能造成数据丢失——它会移除无效的数据片段严重损坏例如检测到 digest 不匹配时甚至会移除整个 SSTable。SEGREGATE将乱序的 row 或 partition 分离到额外的 SSTable 中使每个输出 SSTable 内部保持正确的顺序。从源码理解四种模式的差异在 compaction/compaction.cc 的scrub_compaction::reader中每种模式的行为由_scrub_mode驱动关键逻辑包括maybe_abort_scrub()当发现校验错误时只有ABORT模式会直接抛出compaction_aborted_exceptionscrub compaction found invalid data其他模式则累加_validation_errors计数并继续。on_malformed_sstable_exception()遇到 SSTable 解析异常sstables::malformed_sstable_exception时ABORT模式以及未启用--drop-unfixable-sstables的SEGREGATE模式会中止 scrub而启用了--drop-unfixable-sstables的SEGREGATE模式会标记_failed_to_fix_sstable true并结束当前流最终在任务层面丢弃该无法修复的 SSTable。SEGREGATE模式的特殊处理use_interposer_consumer()返回true通过 interposer consumer 将乱序的 fragment 分隔inject partition start/end到不同的输出桶bucket中finish()时若_bucket_count 0完成描述会显示segregated input into N bucket(s)说明乱序数据被分成了 N 个独立、各自有序的新 SSTable。VALIDATE模式只读取、不重写 SSTable验证通过mutation_fragment_stream_validator流式执行digest 校验依赖 SSTable 组件中存储的校验值。SKIP模式遇到非法 partition 时跳过整个 partitionon_invalid_partition遇到非法 mutation fragment 时跳过对应数据片段对于出现 partition-end 之后的 partition-end 这类情况直接丢弃多余的 partition-end。scrub 的任务完成描述与错误报告统一通过report_validation_error()输出到日志格式为[Scrub compaction keyspace.table] 错误信息; 处理动作便于运维人员定位具体表与损坏位置。三种 quarantine 模式详解--quarantine-mode控制本次 scrub 如何处理已被隔离quarantined的 SSTable取值定义在 compaction/compaction_descriptor.hh 的compaction_type_options::scrub::quarantine_mode枚举中Quarantine 模式行为说明INCLUDE同时处理常规与已隔离的 SSTable默认。EXCLUDE仅处理常规未隔离的 SSTable。ONLY仅处理已隔离的 SSTable。这意味着你可以先用VALIDATE模式找出并隔离损坏的 SSTable之后再用--quarantine-mode ONLY只针对这些被隔离的 SSTable 进行二次分析或处置而不必重新扫描全部数据。quarantine 目录的实现从 sstables/sstables.hh 可以看到SSTable 数据目录下预定义了若干子目录常量其中quarantine_dir quarantine与staging、upload、snapshots、pending_delete一起构成表的子目录集合。SSTable 的状态枚举sstable_state::quarantine与目录quarantine一一对应说明被隔离在存储层是一个真实的文件系统状态而不是简单的逻辑标记。被隔离quarantinedSSTable 的特殊行为官方文档明确列出了被隔离 SSTable 的处置规则理解这些规则对于正确使用 scrub 至关重要参与读操作reads参与流式传输与数据迁移streaming 和 data migration参与修复repairs不参与 compaction但会参与 tombstone-gc 的 overlap 检查。隔离机制的目的有两个一是让损坏的 SSTable远离 compaction——否则 compaction 可能把损坏扩散到更多文件或陷入失败-重试的死循环二是让损坏的 SSTable易于被发现和检索便于后续调查取证。如果不想启用隔离行为可以通过--quarantine-invalid-sstablesfalse显式关闭该参数仅在VALIDATE模式下合法默认值为true。实操示例以下是官方文档提供的标准示例可直接在 ScyllaDB 节点上执行示例 1scrub 某个 keyspace 下的所有表 nodetool scrub mykeyspace示例 2scrub 某个 keyspace 下指定的表 nodetool scrub mykeyspace mytable示例 3以 SEGREGATE 模式 scrub 指定表 nodetool scrub -m SEGREGATE mykeyspace mytable示例 4以 VALIDATE 模式 scrub 指定表且不预先拍快照 nodetool scrub --no-snapshot mykeyspace mytable示例 5以 SEGREGATE 模式 scrub 指定表并丢弃无法修复的 SSTable nodetool scrub -m SEGREGATE --drop-unfixable-sstables mykeyspace mytable在 ScyllaDB 的测试体系中这些行为有对应的自动化验证。例如 test/boost/scrub_test.cc 使用scrub_test_framework构造随机 schema 与损坏数据验证各模式下输出 SSTable 的 fragment 顺序与完整性test/nodetool/test_scrub.py 则从 nodetool 命令层面端到端验证各参数与返回状态。感兴趣的读者可深入这两个文件了解 scrub 的预期行为矩阵。清除损坏 SSTable 的两套标准流程当确认存在损坏 SSTable 后官方文档提供了两套操作流程分别适用于先调查再删除与直接尝试修复并丢弃两种场景。方法一隔离并丢弃Quarantine and Drop该方法的思路是先用只读的VALIDATE模式找出损坏文件并隔离保留样本供调查最后彻底删除。Step 1以 VALIDATE 模式运行 scrub识别并隔离损坏的 SSTable nodetool scrub keyspace_name table_name这一步会把损坏的 SSTable 移动到表数据目录下的quarantine子目录中即数据目录/keyspace/table-uuid/quarantine/。隔离后的文件按上文规则参与读、流式传输与修复但不再参与 compaction。如果想跳过隔离这一步可以追加--quarantine-invalid-sstablesfalse。Step 2可选保留隔离文件以供分析在永久删除损坏的 SSTable 之前建议先将其复制到 ScyllaDB 数据目录之外的位置交由 ScyllaDB RD 团队分析损坏根因 cp -r /path/to/data/keyspace_name/table_dir/quarantine /path/to/backup/location/Step 3使用 dropquarantinedsstables 删除被隔离的 SSTable nodetool dropquarantinedsstables keyspace_name table_name该命令会从指定表中永久移除被隔离的 SSTable。它同样支持省略参数以作用于所有 keyspace、所有表或只指定 keyspace 作用于其中全部表详见 dropquarantinedsstables 命令文档。方法二SEGREGATE drop-unfixable 自动处置该方法的思路是能修复的尽量修复不能修复的自动丢弃全程无需人工干预。注意此方法只适用于 SEGREGATE 模式真正能帮上忙的那类损坏——即损坏至少部分表现为 partition 或 row 乱序的场景。对于纯字节级损坏SEGREGATE 无法起效应使用方法一。Step 1以 SEGREGATE 模式并携带--drop-unfixable-sstables运行 scrub nodetool scrub -m SEGREGATE --drop-unfixable-sstables keyspace_name table_name该命令会完成以下工作尽可能对乱序数据执行分离segregate与修复移除错误数据自动丢弃无法修复的 SSTable从可恢复的数据中生成新的、顺序正确的新 SSTable。从源码角度看这一步正是scrub_compaction在segregate模式下配合drop_unfixable选项的行为乱序 fragment 被 interposer consumer 分隔进多个有序输出桶而解析失败malformed_sstable_exception的 SSTable 被标记为_failed_to_fix_sstable并跳过输出最终只保留可恢复部分生成的、有序的新 SSTable。使用建议与注意事项综合官方文档与源码实现给出以下实践建议默认先用 VALIDATE 摸清情况VALIDATE 是只读模式不会重写数据最适合作为第一步来评估损坏范围与严重程度配合默认的隔离行为损坏文件会被集中到quarantine目录方便统一调查。涉及 counter 表时谨慎使用 SKIP旧版--skip-corrupted即SKIP模式会跳过损坏数据可能导致数据丢失或 counter 语义不一致文档明确将其标记为已弃用并建议改用--mode。利用 quarantine 模式组合做定向处置先用VALIDATE默认INCLUDE全量扫描隔离损坏文件再用--quarantine-mode ONLY只针对隔离文件执行后续处理可显著减少重复扫描成本。务必先备份再删除方法一中的 Step 2 复制隔离文件到数据目录外是调查损坏根因、避免不可逆丢失的关键一步不建议跳过。明确两套方法的适用范围方法二SEGREGATE drop-unfixable仅适用于乱序型损坏方法一隔离 dropquarantinedsstables则对各类损坏都适用是更通用、更安全的兜底方案。异常场景的预期行为若 scrub 因数据损坏在ABORT模式下中止nodetool 会返回aborted状态若完成但存在校验错误返回validation_errors状态见 api/scrub_status.hh运维脚本可据此区分结果。本文所描述的语法、参数与行为均以当前仓库为准命令参数解析见 api/storage_service.cc 的parse_scrub_options()模式枚举定义见 compaction/compaction_descriptor.hh核心执行逻辑见 compaction/compaction.cc 的scrub_compaction目录布局见 sstables/sstables.hh自动化验证见 test/boost/scrub_test.cc 与 test/nodetool/test_scrub.py。实际使用时请以你所部署的 ScyllaDB 版本所附带的nodetool help scrub输出为准。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ScyllaDB nodetool scrub 完全指南：识别与修复损坏 SSTable 的四种模式与隔离机制
ScyllaDB nodetool scrub 完全指南识别与修复损坏 SSTable 的四种模式与隔离机制【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbnodetool scrub是 ScyllaDB 提供的用于识别并修复损坏 SSTable 的运维命令它能够移除错误数据、清理已超过表gc_grace周期的 tombstone 行并修复乱序的 row 与 partition。本文以 ScyllaDB 官方操作文档为骨架结合compaction/、api/、sstables/目录下的真实实现与test/中的测试用例系统讲解 scrub 的全部参数、四种 scrub 模式、三种 quarantine 模式以及两套清除损坏 SSTable的完整实操流程。读完本文你将能根据不同的损坏类型选择正确的 scrub 策略并安全地隔离、保留或删除损坏的 SSTable。scrub 能做什么命令概述scrub 的核心工作是对 SSTable 执行反序列化 重新序列化deserialize reserialize在此过程中识别并尽可能修复以下三类问题损坏的数据corrupted data由于磁盘故障、异常断电等原因导致的数据字节错误已过期 tombstone超过表gc_grace周期、可以安全清除的 tombstone 行乱序的 row / partitionSSTable 内行或分区顺序违反排序约束的情况。需要注意的是正如官方文档所指出的并非所有类型的损坏都能被 scrub 修复或跳过。scrub 针对的是数据层面的结构性问题对于超出其能力范围的损坏需要结合下面介绍的 quarantine 机制来隔离和处置。在 ScyllaDB 中scrub 本质上是一次特殊的 compactioncompaction_type::Scrub。从源码看scrub 的入口链路为nodetool scrub→ REST API/storage_service/keyspace_scrub/{keyspace}见 api/storage_service.cc 中的ss::scrub处理器与 api/api-doc/storage_service.json 中的接口定义→ 创建scrub_sstables_compaction_task_impl任务 → 由compaction/compaction.cc中的scrub_compaction类实际执行。scrub 结束后的状态码定义在 api/scrub_status.hhsuccessful 0、aborted、validation_errors其中unable_to_cancel在 Scylla 中未使用仅为了与 nodetool API 保持兼容。命令语法与完整参数说明scrub 的完整命令语法如下nodetool [(-h host | --host host)] [(-p port | --port port)] [(-pp | --print-port)] [(-pw password | --password password)] [(-pwf passwordFilePath | --password-file passwordFilePath)] [(-ns | --no-snapshot)] [(-s | --skip-corrupted)] [(-m scrub_mode | --mode scrub_mode)] [(-q quarantine_mode | --quarantine-mode quarantine_mode)] [--drop-unfixable-sstables] [--] keyspace [table...] 支持的 scrub 模式VALIDATE、ABORT、SKIP、SEGREGATE 支持的 quarantine 模式INCLUDE、EXCLUDE、ONLY参数表参数说明-ns/--no-snapshotscrub 开始前不拍摄所有被 scrub 表的快照默认false即默认会先拍快照。-s/--skip-corrupted跳过损坏的 row 或 partition即使是对 counter 表进行 scrub 时也生效。已弃用请改用--mode默认false-m scrub_mode/--mode scrub_mode如何处理损坏数据取值为VALIDATE\|ABORT\|SKIP\|SEGREGATE之一默认VALIDATE会覆盖--skip-corrupted。-q quarantine_mode/--quarantine-mode quarantine_mode如何处理已被隔离的 SSTable取值为INCLUDE\|EXCLUDE\|ONLY之一默认INCLUDE。--drop-unfixable-sstables丢弃无法修复的 SSTable而不是中止整个 scrub仅在与--modeSEGREGATE组合时有效。--quarantine-invalid-sstables true\|false损坏的 SSTable 是否应被隔离默认true仅在与--modeVALIDATE组合时有效。--用于将命令行选项与参数列表分隔开当参数可能被误认为命令行选项时很有用。keyspace要 scrub 的 keyspace。[table...]可选。一个或多个要 scrub 的表。默认情况下keyspace 中的所有表都会被 scrub。参数背后的实现逻辑以上参数在 REST API 层被逐一解析逻辑集中在 api/storage_service.cc 的parse_scrub_options()函数中-m/--mode与-s/--skip-corrupted的优先级如果未显式传入scrub_mode则回退读取skip_corrupted参数为true时模式被置为SKIP如果显式传入了scrub_mode则完全覆盖skip_corrupted。这与文档中--mode会覆盖--skip-corrupted的说明一致。默认快照只有当disable_snapshot为false且确实有表需要 scrub 时才会生成快照标签pre-scrub-时间戳随后在ss::scrub处理器中通过db::snapshot_optionsskip_flush false即不跳过 flush执行快照。这解释了为什么默认情况下 scrub 会先拍快照。参数校验drop_unfixable_sstables在非SEGREGATE模式下传入会抛出bad_param_exceptiononly valid when scrub_mode is SEGREGATEquarantine_invalid_sstables在非VALIDATE模式下传入同样会报错only valid when scrub_mode is VALIDATE。这些约束与命令语法中的标注完全对应。quarantine 模式解析quarantine_mode默认值为INCLUDEEXCLUDE/ONLY分别对应枚举compaction_type_options::scrub::quarantine_mode的exclude/only见 compaction/compaction_descriptor.hh。四种 scrub 模式详解scrub 的四种模式定义在 compaction/compaction_descriptor.hh 的compaction_type_options::scrub::mode枚举中其行为差异如下Scrub 模式行为说明VALIDATE只读模式在 scrub 过程中报告发现的所有损坏但不修复它们。同时会通过校验存储的 digest若存在来验证组件完整性。默认情况下损坏的 SSTable 会被移动到 quarantine 子目录从而避免参与 compaction。默认模式ABORT出现第一个校验错误时立即中止 scrub。SKIP跳过损坏的 row 或 partition等同于旧版--skip-corrupted选项。警告该模式可能造成数据丢失——它会移除无效的数据片段严重损坏例如检测到 digest 不匹配时甚至会移除整个 SSTable。SEGREGATE将乱序的 row 或 partition 分离到额外的 SSTable 中使每个输出 SSTable 内部保持正确的顺序。从源码理解四种模式的差异在 compaction/compaction.cc 的scrub_compaction::reader中每种模式的行为由_scrub_mode驱动关键逻辑包括maybe_abort_scrub()当发现校验错误时只有ABORT模式会直接抛出compaction_aborted_exceptionscrub compaction found invalid data其他模式则累加_validation_errors计数并继续。on_malformed_sstable_exception()遇到 SSTable 解析异常sstables::malformed_sstable_exception时ABORT模式以及未启用--drop-unfixable-sstables的SEGREGATE模式会中止 scrub而启用了--drop-unfixable-sstables的SEGREGATE模式会标记_failed_to_fix_sstable true并结束当前流最终在任务层面丢弃该无法修复的 SSTable。SEGREGATE模式的特殊处理use_interposer_consumer()返回true通过 interposer consumer 将乱序的 fragment 分隔inject partition start/end到不同的输出桶bucket中finish()时若_bucket_count 0完成描述会显示segregated input into N bucket(s)说明乱序数据被分成了 N 个独立、各自有序的新 SSTable。VALIDATE模式只读取、不重写 SSTable验证通过mutation_fragment_stream_validator流式执行digest 校验依赖 SSTable 组件中存储的校验值。SKIP模式遇到非法 partition 时跳过整个 partitionon_invalid_partition遇到非法 mutation fragment 时跳过对应数据片段对于出现 partition-end 之后的 partition-end 这类情况直接丢弃多余的 partition-end。scrub 的任务完成描述与错误报告统一通过report_validation_error()输出到日志格式为[Scrub compaction keyspace.table] 错误信息; 处理动作便于运维人员定位具体表与损坏位置。三种 quarantine 模式详解--quarantine-mode控制本次 scrub 如何处理已被隔离quarantined的 SSTable取值定义在 compaction/compaction_descriptor.hh 的compaction_type_options::scrub::quarantine_mode枚举中Quarantine 模式行为说明INCLUDE同时处理常规与已隔离的 SSTable默认。EXCLUDE仅处理常规未隔离的 SSTable。ONLY仅处理已隔离的 SSTable。这意味着你可以先用VALIDATE模式找出并隔离损坏的 SSTable之后再用--quarantine-mode ONLY只针对这些被隔离的 SSTable 进行二次分析或处置而不必重新扫描全部数据。quarantine 目录的实现从 sstables/sstables.hh 可以看到SSTable 数据目录下预定义了若干子目录常量其中quarantine_dir quarantine与staging、upload、snapshots、pending_delete一起构成表的子目录集合。SSTable 的状态枚举sstable_state::quarantine与目录quarantine一一对应说明被隔离在存储层是一个真实的文件系统状态而不是简单的逻辑标记。被隔离quarantinedSSTable 的特殊行为官方文档明确列出了被隔离 SSTable 的处置规则理解这些规则对于正确使用 scrub 至关重要参与读操作reads参与流式传输与数据迁移streaming 和 data migration参与修复repairs不参与 compaction但会参与 tombstone-gc 的 overlap 检查。隔离机制的目的有两个一是让损坏的 SSTable远离 compaction——否则 compaction 可能把损坏扩散到更多文件或陷入失败-重试的死循环二是让损坏的 SSTable易于被发现和检索便于后续调查取证。如果不想启用隔离行为可以通过--quarantine-invalid-sstablesfalse显式关闭该参数仅在VALIDATE模式下合法默认值为true。实操示例以下是官方文档提供的标准示例可直接在 ScyllaDB 节点上执行示例 1scrub 某个 keyspace 下的所有表 nodetool scrub mykeyspace示例 2scrub 某个 keyspace 下指定的表 nodetool scrub mykeyspace mytable示例 3以 SEGREGATE 模式 scrub 指定表 nodetool scrub -m SEGREGATE mykeyspace mytable示例 4以 VALIDATE 模式 scrub 指定表且不预先拍快照 nodetool scrub --no-snapshot mykeyspace mytable示例 5以 SEGREGATE 模式 scrub 指定表并丢弃无法修复的 SSTable nodetool scrub -m SEGREGATE --drop-unfixable-sstables mykeyspace mytable在 ScyllaDB 的测试体系中这些行为有对应的自动化验证。例如 test/boost/scrub_test.cc 使用scrub_test_framework构造随机 schema 与损坏数据验证各模式下输出 SSTable 的 fragment 顺序与完整性test/nodetool/test_scrub.py 则从 nodetool 命令层面端到端验证各参数与返回状态。感兴趣的读者可深入这两个文件了解 scrub 的预期行为矩阵。清除损坏 SSTable 的两套标准流程当确认存在损坏 SSTable 后官方文档提供了两套操作流程分别适用于先调查再删除与直接尝试修复并丢弃两种场景。方法一隔离并丢弃Quarantine and Drop该方法的思路是先用只读的VALIDATE模式找出损坏文件并隔离保留样本供调查最后彻底删除。Step 1以 VALIDATE 模式运行 scrub识别并隔离损坏的 SSTable nodetool scrub keyspace_name table_name这一步会把损坏的 SSTable 移动到表数据目录下的quarantine子目录中即数据目录/keyspace/table-uuid/quarantine/。隔离后的文件按上文规则参与读、流式传输与修复但不再参与 compaction。如果想跳过隔离这一步可以追加--quarantine-invalid-sstablesfalse。Step 2可选保留隔离文件以供分析在永久删除损坏的 SSTable 之前建议先将其复制到 ScyllaDB 数据目录之外的位置交由 ScyllaDB RD 团队分析损坏根因 cp -r /path/to/data/keyspace_name/table_dir/quarantine /path/to/backup/location/Step 3使用 dropquarantinedsstables 删除被隔离的 SSTable nodetool dropquarantinedsstables keyspace_name table_name该命令会从指定表中永久移除被隔离的 SSTable。它同样支持省略参数以作用于所有 keyspace、所有表或只指定 keyspace 作用于其中全部表详见 dropquarantinedsstables 命令文档。方法二SEGREGATE drop-unfixable 自动处置该方法的思路是能修复的尽量修复不能修复的自动丢弃全程无需人工干预。注意此方法只适用于 SEGREGATE 模式真正能帮上忙的那类损坏——即损坏至少部分表现为 partition 或 row 乱序的场景。对于纯字节级损坏SEGREGATE 无法起效应使用方法一。Step 1以 SEGREGATE 模式并携带--drop-unfixable-sstables运行 scrub nodetool scrub -m SEGREGATE --drop-unfixable-sstables keyspace_name table_name该命令会完成以下工作尽可能对乱序数据执行分离segregate与修复移除错误数据自动丢弃无法修复的 SSTable从可恢复的数据中生成新的、顺序正确的新 SSTable。从源码角度看这一步正是scrub_compaction在segregate模式下配合drop_unfixable选项的行为乱序 fragment 被 interposer consumer 分隔进多个有序输出桶而解析失败malformed_sstable_exception的 SSTable 被标记为_failed_to_fix_sstable并跳过输出最终只保留可恢复部分生成的、有序的新 SSTable。使用建议与注意事项综合官方文档与源码实现给出以下实践建议默认先用 VALIDATE 摸清情况VALIDATE 是只读模式不会重写数据最适合作为第一步来评估损坏范围与严重程度配合默认的隔离行为损坏文件会被集中到quarantine目录方便统一调查。涉及 counter 表时谨慎使用 SKIP旧版--skip-corrupted即SKIP模式会跳过损坏数据可能导致数据丢失或 counter 语义不一致文档明确将其标记为已弃用并建议改用--mode。利用 quarantine 模式组合做定向处置先用VALIDATE默认INCLUDE全量扫描隔离损坏文件再用--quarantine-mode ONLY只针对隔离文件执行后续处理可显著减少重复扫描成本。务必先备份再删除方法一中的 Step 2 复制隔离文件到数据目录外是调查损坏根因、避免不可逆丢失的关键一步不建议跳过。明确两套方法的适用范围方法二SEGREGATE drop-unfixable仅适用于乱序型损坏方法一隔离 dropquarantinedsstables则对各类损坏都适用是更通用、更安全的兜底方案。异常场景的预期行为若 scrub 因数据损坏在ABORT模式下中止nodetool 会返回aborted状态若完成但存在校验错误返回validation_errors状态见 api/scrub_status.hh运维脚本可据此区分结果。本文所描述的语法、参数与行为均以当前仓库为准命令参数解析见 api/storage_service.cc 的parse_scrub_options()模式枚举定义见 compaction/compaction_descriptor.hh核心执行逻辑见 compaction/compaction.cc 的scrub_compaction目录布局见 sstables/sstables.hh自动化验证见 test/boost/scrub_test.cc 与 test/nodetool/test_scrub.py。实际使用时请以你所部署的 ScyllaDB 版本所附带的nodetool help scrub输出为准。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考