Судебная экспертиза базы данных Apache Cassandra

Экспертиза Apache Cassandra нужна, когда спор зависит от распределённых данных, файлов SSTable и журналов фиксации операций (commit logs), временных меток и маркеров удаления (tombstones), репликации, уровня согласованности (consistency level), сверки и восстановления согласованности реплик (repair), моментальных снимков, сбоя, производительности или миграции. Специалист устанавливает версии узлов, устройство кластера и центры обработки данных, средство распределения данных, диапазоны токенов (token ranges), схему, правила репликации и историю обслуживания. Ключ раздела (partition key) определяет размещение данных и поэтому должен быть указан для исследования конкретной записи. Это специализированное направление экспертизы баз данных и СУБД.

Предварительно можно оценить, какие гипотезы удастся проверить. Для первого обращения достаточно схемы кластера, версий, перечня файлов SSTable, журналов фиксации операций и снимков по узлам, истории сверки реплик и спорного ключа раздела или периода. Если уплотнение (compaction) уже удалило прежние значения и маркеры удаления, снимков нет, а аудит или CDC не были включены, точная история может быть недоступна. Это лучше установить до начала полноценного исследования, чтобы вовремя сохранить оставшиеся источники и уточнить вопросы.

Если кластер ваш или вы действуете с согласия его владельца, первое действие — nodetool snapshot на каждом относящемся к задаче узле; если спорный кластер принадлежит другой стороне, не запускайте ничего: фиксацию проводят по определению суда с участием эксперта. Снимок создаёт жёсткие ссылки на текущие SSTable: он не копирует данные и защищает файлы от удаления уплотнением. По умолчанию команда сначала сбрасывает на диск данные из памяти — на нагруженном узле это создаёт заметную нагрузку ввода-вывода и новые SSTable, зато снимок включает данные, подтверждённые к этому моменту. Режим --skip-flush выполняется мгновенно, но несброшенные данные в снимок не войдут. Режим выбирают заранее и записывают: происхождение SSTable, созданных самой командой, должно быть видно из заключения. Копировать каталоги данных работающей Cassandra без снимка бессмысленно: уплотнение непрерывно создаёт и удаляет SSTable, и набор файлов окажется несогласованным. Место, занятое снимком, освобождают после вывоза копии.

Если уже по присланным материалам видно, что ответ получить нельзя, мы не берём задачу в работу и сразу сообщаем об этом. Принятая задача не обязательно завершится положительным выводом. Если это выясняется только в ходе исследования, работа считается выполненной: заключение объясняет, почему ответ получить нельзя и каких данных не хватило. Например, заключение может обосновать, что срок хранения маркеров удаления истёк и записи уже уплотнены. Назначать ли после этого дополнительную или повторную экспертизу, решает назначивший её орган. При частичной возможности ответа в заключении указывают, на какие вопросы он получен, на какие — нет и почему.

Кто и как снимет копию, определяют после ознакомления с объектом. Копию может снять заказчик или его администратор по согласованному плану, наш специалист — удалённо либо с выездом в рамках отдельной консультации, либо эксперт в ходе экспертизы. Выбор зависит от сложности системы, доступности и трудоёмкости: моментальные снимки узлов снимают по-разному на одиночном сервере и на нагруженном кластере. Если инфраструктура находится под контролем другой стороны, порядок доступа определяет суд; состояние системы фиксируют с участием эксперта.

До снятия снимка не запускайте сверку реплик, cleanup, upgradesstables, scrub или загрузку резервной копии поверх единственного состояния: эти операции переписывают SSTable, распространяют выбранную версию данных и удаляют маркеры удаления. Уплотнение идёт само; на время копирования его можно приостановить штатной командой для нужных таблиц, но надолго оставлять кластер без уплотнения нельзя — число SSTable растёт, чтения замедляются, диск заполняется. Поэтому снимок делают в первые часы, а не откладывают. Зафиксируйте результаты nodetool status и nodetool describering, схему, принадлежность диапазонов токенов, время и часовой пояс каждого узла, очередь ожидающих уплотнений и историю сверки реплик. Эти действия выполняет владелец системы или уполномоченный им администратор; если кластер принадлежит другой стороне, сохранение доказательств организуют через суд.

Сверку реплик надолго откладывать нельзя. Её укладывают в интервал gc_grace_seconds — по умолчанию это десять суток, а срок экспертизы больше. Если реплика пропустила удаление и была недоступна дольше этого интервала, маркер удаления на остальных репликах успевает исчезнуть — тогда прежнее значение может вернуться на боевом кластере. На здоровом кластере, где удаление дошло до всех реплик, отсрочка сверки ничего не воскрешает; проверяют это по журналам узлов, состоянию кластера и истории сверок. Поэтому снимок создают сразу и сверку возобновляют, а не ждут окончания исследования. Если снять копию за это время нельзя, увеличить gc_grace_seconds может владелец кластера — заранее, с записью даты, исполнителя и причины: маркеров удаления станет больше, чтения замедлятся, а само изменение раскрывают в заключении.

Если Cassandra предоставлена как управляемый сервис, ни cassandra.yaml, ни nodetool, ни каталога журналов фиксации, ни доступа к файлам SSTable у заказчика нет, а фоновыми операциями управляет провайдер. Тогда состав материалов другой: штатные снимки и точки восстановления провайдера с идентификаторами, выгрузки через клиентское подключение, журналы операций, метрики и события обслуживания.

Почему Cassandra исследуют как распределённую систему

Один узел хранит только принадлежащие ему диапазоны токенов и реплики; его локальное состояние может отличаться из-за выбранного уровня согласованности, недоступности других узлов, подсказок отложенной доставки, потоковой передачи и сверки реплик. Значение строки собирается по временным меткам из нескольких неизменяемых SSTable и таблицы в памяти (memtable). Поэтому копия одного файла Data.db или результат одного запроса не описывают кластер без сведений о его устройстве и применённом уровне согласованности.

На первом этапе:

• устанавливают версии и их совместимость, имя кластера, средство распределения данных (partitioner), определитель сетевого расположения (snitch), центры обработки данных и стойки;
• фиксируют узлы, их host ID, токены, принадлежность диапазонов, а также события ввода узлов в кластер, вывода из кластера и замены;
• описывают пространства ключей, правила и коэффициенты репликации, таблицы, ключи разделов и кластеризации;
• инвентаризируют все компоненты SSTable, журналы фиксации операций, сохранённые кэши, подсказки отложенной доставки, снимки и добавочные резервные копии;
• собирают системные и отладочные журналы, журналы сборщика мусора, показатели работы, историю уплотнения и сверки реплик;
• проверяют аудит, полное журналирование запросов и CDC только в пределах фактической конфигурации;
• сопоставляют клиентский уровень согласованности, временные метки, правила повторных и опережающих запросов и журналы приложений.

Что может и чего не может установить эксперт

При достаточных материалах можно определить версии ячеек и маркеры удаления в SSTable, операции записи и изменения данных в журналах фиксации, распределение реплик, состояние снимков, сверки реплик и уплотнения, расхождения между узлами, причины потери или восстановления ранее удалённых данных и полноту миграции. Вывод привязывают к ключу раздела, временной метке, исходному узлу и компоненту файла.

При достаточных материалах эксперт может установить:

• какие значения и временные метки представлены для раздела на каждой доступной реплике;
• какие операции записи и изменения данных сохранились в журнале фиксации и были ли они уже сброшены в SSTable;
• имеются ли маркеры удаления, сведения об истечении TTL и старые версии до уплотнения;
• какие диапазоны токенов и компоненты данных входят в снимок или резервную копию;
• происходили ли сверка реплик, потоковая передача, уплотнение, замена узла или изменение устройства кластера;
• соответствуют ли настройки репликации и согласованности заданным требованиям;
• какие действия отражены в источниках аудита, полного журналирования запросов или CDC;
• полностью ли перенесены схема и данные по диапазонам токенов.

Временная метка ячейки может задаваться клиентом и не является автоматически временем, когда конкретный человек выполнил действие. Правило «побеждает последняя запись» (last-write-wins) выбирает значение по временной метке, а рассинхронизация часов или ошибочная клиентская метка могут сделать старое логическое действие «новее». Журнал фиксации обеспечивает сохранность ещё не сброшенной таблицы в памяти, но не является бессрочным аудитом всех чтений и пользователей. Для атрибуции нужны журналы приложения, проверки подлинности, аудита и сетевой инфраструктуры.

Материалы для исследования

Сбор планируют по каждому относящемуся к задаче узлу. Для каждого каталога, файла и выгрузки указывают источник — узел и его host ID, путь и носитель, — исполнителя, средство сбора и его версию, точные команды и параметры, время начала и окончания с часовым поясом, размер и SHA-256. Неизменяемую мастер-копию отделяют от рабочей. Для каждой передачи регистрируют отправителя, получателя, время и носитель; при получении SHA-256 вычисляют повторно и сверяют. Компоненты одной SSTable имеют общий дескриптор и исследуются комплектом; файл Data.db нельзя отделять от индексов, статистики, TOC и контекста схемы.

В комплект обычно включают:

• cassandra.yaml, конфигурации rackdc, logback и среды, версии Java и Cassandra;
• схему CQL, выгрузки system_schema, правила репликации пространств ключей и параметры таблиц;
• все компоненты SSTable для относящихся к задаче таблиц, снимки и добавочные резервные копии;
• каталог commitlog, исходные сегменты и индексы CDC, подсказки отложенной доставки и при необходимости сохранённые кэши;
• результаты nodetool status, describering, gossipinfo, netstats, compactionstats, tpstats и перечень снимков за спорный период;
• system.log, debug.log, gc.log, журналы аудита и полного журналирования запросов, данные внешнего наблюдения;
• историю сверки реплик и уплотнения, события потоковой передачи, ввода и замены узлов, cleanup и scrub;
• журналы приложений и драйверов, уровни согласованности, правила повторных и опережающих запросов, клиентские временные метки и сведения о синхронизации времени;
• техническое задание, соглашение об уровне обслуживания (SLA), правила резервного копирования и сверки реплик, таблица соответствия при миграции и контрольные ключи разделов.

Шифрованные тома, учётные данные доступа к узлам и ключи передают отдельно. Команды nodetool и запросы CQL в работающей системе могут влиять на нагрузку и журналы, поэтому протоколируют команду, средство и его версию, узел, время, результат и наблюдаемое влияние.

Копию со сведениями о людях или охраняемой законом тайной передают на законном основании. При назначенной экспертизе объекты передаёт назначивший орган, вне процесса — обладатель сведений и лишь в необходимом объёме. До передачи определяют, что можно обезличить или исключить без ущерба исследованию. Эксперт не разглашает сведения, ставшие известными ему в связи с исследованием, а рабочие копии удаляет по окончании работы.

Журнал фиксации операций, таблица в памяти и SSTable

При записи Cassandra добавляет операцию изменения в журнал фиксации и изменяет таблицу в памяти. После сброса данные из памяти образуют неизменяемую SSTable, а сегменты журнала, которые больше не нужны для несброшенных данных, могут быть переиспользованы. После сбоя Cassandra воспроизводит фактически сохранившиеся пригодные записи журнала. Попадание подтверждённой клиенту записи в восстановленное состояние зависит от commitlog_sync, его периода или окна, уровня согласованности, состояния реплик и сохранности файлов. Журнал фиксации обеспечивает устойчивость записи, но не является постоянным архивом.

SSTable состоит из согласованного набора компонентов. Data.db содержит строки, индекс и сводка помогают поиску, фильтр Блума ускоряет проверку наличия, статистика содержит временные метки, маркеры удаления, сведения о сверке реплик и другие метаданные, а TOC перечисляет состав. Форматы зависят от версии; совместимые автономные средства запускают только на копии.

Обновления не переписывают прежнюю SSTable на месте. Новая версия попадает в новую таблицу в памяти, а затем в SSTable; при чтении результат собирается по временным меткам. Уплотнение объединяет SSTable и при выполнении условий удаляет устаревшие версии и маркеры удаления. Поэтому физическое наличие нескольких значений нормально, а их исчезновение после уплотнения не доказывает ручного удаления файла.

Временные метки, TTL и маркеры удаления

Cassandra разрешает клиенту задавать временную метку записи. При конфликте на уровне ячеек действует правило «побеждает последняя запись», поэтому решающей становится наибольшая временная метка независимо от фактического порядка доставки. Рассинхронизация часов, неверная клиентская метка или повторный запрос могут изменить видимый результат. Эксперт проверяет настройки драйвера, часы узлов и приложения и не отождествляет микросекундную метку с доказанным временем действия человека.

Команда DELETE создаёт маркер удаления; истечение TTL также переводит данные в удалённое состояние. Маркеры должны достаточно долго распространяться между репликами и участвовать в сверке, после чего уплотнение может их удалить. Если одна реплика пропустила удаление, а маркер на других уже исчез, старое значение способно восстановиться. Для установления причины исследуют gc_grace_seconds, интервалы и историю сверки реплик, периоды недоступности, подсказки отложенной доставки, уплотнение и значения на всех репликах.

Моментальные снимки, резервные копии и восстановление

Локальный снимок узла создаёт жёсткие ссылки на текущие SSTable; для кластера нужны снимки всех необходимых узлов и диапазонов токенов, схема и сведения об устройстве кластера. Охват всех диапазонов токенов не доказывает, что данные зафиксированы в один момент. Для каждого узла записывают начало и окончание создания снимка, часовой пояс, состояние синхронизации часов и оценку неопределённости; вывод об общем времени ограничивают этими данными.

Поведение nodetool snapshot зависит от версии: команда может сначала выполнить сброс и тем самым создать новые SSTable и изменить потребность в сегментах журнала фиксации. Вариант --skip-flush снижает это воздействие, но не включает данные несброшенных таблиц в памяти. Выбор режима и его последствия фиксируют до запуска. Добавочные резервные копии сохраняют ссылки на новые SSTable после сброса, но без базового снимка и настроенного архивирования журнала фиксации сами по себе не позволяют восстановить произвольный момент.

Восстановление с последующим воспроизведением журнала фиксации возможно только при заранее настроенных архивации и восстановлении сегментов и наличии полной пригодной последовательности. Обычные активные сегменты, впоследствии переиспользованные системой, нельзя считать архивом.

Восстановление может выполняться копированием в кластер с подходящим устройством, с помощью sstableloader или nodetool import в зависимости от задачи. Оно меняет состояние кластера и может распространить данные, поэтому его проверяют на отдельной среде. Устанавливают совместимость схемы, средство распределения данных, токены, временные метки, метаданные о выполненной сверке реплик (repairedAt) и полноту компонентов SSTable.

Удалённые значения иногда остаются в старых SSTable или снимках до уплотнения и окончательной очистки. Если они удалены из всех доступных копий, журналы фиксации переиспользованы, а резервной копии нет, восстановление невозможно. Вторая реплика не гарантирует наличия архива: сверка реплик, а при подходящем уровне согласованности и настройке — сверка во время чтения, могут согласовать затронутые данные. Если спор целиком о том, что и когда изменилось в записях, требуется экспертиза изменений и удаления данных.

Репликация, согласованность и сверка реплик

Правило репликации определяет реплики для диапазона токенов, а уровень согласованности — сколько ответов координатор требует от операции. Для оценки конкретной записи нужны уровни согласованности чтения и записи, коэффициент репликации, доступность узлов, отложенная доставка по подсказкам, повторные запросы и временные метки. Формула кворума применима только к фактической конфигурации и с учётом иных нарушений.

Сверка реплик сравнивает их данные и передаёт различия, выбирая версии по правилам Cassandra. Она необходима для согласованности, но изменяет данные и способна распространить нежелательное значение. Проверяют полную или добавочную сверку, метаданные repairedAt, незавершённые сеансы, историю, диапазоны и факт завершения. Запуск сверки после инцидента до копирования может изменить исходное состояние и удалить технические признаки первоначального расхождения.

Аудит, полное журналирование запросов и CDC

При включённом аудите выбранные категории событий записываются через настроенное средство ведения журнала; его фильтры и срок хранения задают отдельно. Полное журналирование запросов предназначено для записи операций CQL в бинарный журнал в пределах заданного режима; задним числом такие записи не появляются. Охват, пропущенные события, архивирование и сохранность проверяют по конфигурации конкретной версии.

CDC действует только для таблиц с cdc=true, когда эта функция включена на узле. Cassandra создаёт жёсткую ссылку на сегмент журнала фиксации в cdc_raw и индекс с устойчивым смещением; обработчик должен читать только подтверждённую часть. Пространство CDC может заполниться, после чего новые записи в такие таблицы отклоняются. CDC даёт материал для реконструкции операций изменения, но не является готовым аудитом действий конкретного человека.

Сбои и производительность

Сопоставляют системные, отладочные журналы и журналы сборщика мусора, пропущенные сообщения, пулы потоков, задержки координатора, превышения времени ожидания, ошибки недоступности, накопившиеся уплотнения, чтение большого числа маркеров удаления, память и паузы сборщика мусора, задержки диска и сети, синхронизацию журнала фиксации, подсказки отложенной доставки, потоковую передачу, сверку реплик и повторные запросы драйвера. system.log служит исходной точкой, debug.log подробнее отражает сброс и уплотнение, но срок его хранения ограничен.

По одному медленному запросу нельзя установить причину без сведений о распределении ключей разделов, модели данных, уровне согласованности, репликах, количестве SSTable, маркерах удаления и нагрузке. Испытания проводят на копии или контролируемом стенде. Риск крупных разделов и чтения множества маркеров удаления оценивают по фактическим показателям и метаданным SSTable, а не только по общим рекомендациям. Замедления и отказы сами по себе исследует экспертиза производительности и сбоев СУБД.

Как проверить миграцию Cassandra

Сопоставляют пространства ключей, репликацию и durable_writes, таблицы, ключи разделов, ключи и порядок кластеризации, столбцы и типы CQL, статические столбцы, счётчики, коллекции, кортежи, UDT, значения по умолчанию, индексы, материализованные представления, идентификаторы таблиц и все значимые параметры, включая сжатие, уплотнение, кэширование, CDC, TTL и gc_grace_seconds. Отдельно проверяют UDF/UDA, роли и права, содержимое и репликацию системного пространства ключей авторизации, настройки проверки подлинности и разрешений. Изменение первичного ключа означает изменение распределения и модели запросов.

Для технической проверки полноты по воспроизводимому алгоритму сверяют все предусмотренные диапазоны токенов, ключи разделов и ячейки либо равнозначные агрегаты и контрольные значения, учитывая временные метки, маркеры удаления и TTL. Покрытие всех диапазонов токенов не подтверждает единый момент времени: фиксируют время каждого узла и снимка, синхронизацию часов и неопределённость. Устойчивую выборку ключей применяют только как выборочный контроль с явно оговорённым уровнем уверенности. Фиксируют снимки, sstableloader или импорт, момент переключения, параллельную запись в обе системы, отклонённые изменения, повторные запросы и поздно поступившие события. Равное число разделов не подтверждает равенство ячеек и временных меток. После загрузки проверяют сверку реплик и фактическую доступность при предусмотренных уровнях согласованности. Когда предметом спора становится сам перенос, а не устройство базы, требуется экспертиза миграции баз данных.

Примеры вопросов на экспертизу

При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Вопросы о виновности, умысле, правовой квалификации события, нарушении договора и ответственности разрешает суд или иной уполномоченный орган. Эксперт отвечает на поставленные вопросы в пределах специальных знаний и представленных материалов; о неясности вопроса, выходе за пределы компетенции или недостаточности материалов он в установленном порядке сообщает суду, органу или лицу, назначившим экспертизу.

До назначения стороны могут предложить уполномоченному органу формулировки технических вопросов. Для Cassandra полезно указать кластер, пространство ключей и таблицу, ключ раздела или диапазон токенов, период, часовой пояс и применённый уровень согласованности. Например, можно предложить исследовать временные метки и маркеры удаления для раздела X и связанные технические идентификаторы либо сопоставить актуальные значения раздела X на репликах A, B и C. Дополнительные примеры:

1. Какие значения, временные метки, сроки жизни (TTL) и маркеры удаления представлены для раздела X на доступных репликах?
2. Какие операции записи и изменения данных для заданной таблицы сохранились в журналах фиксации?
3. Охватывают ли снимки и добавочные резервные копии необходимые диапазоны токенов и к какому времени относится снимок каждого узла?
4. Имеются ли расхождения реплик и чем подтверждается их происхождение?
5. Могли ли сверка реплик, уплотнение и настройка gc_grace_seconds привести к восстановлению удалённых данных?
6. Какие изменения устройства кластера, потоковая передача и замена узлов происходили?
7. Какие действия отражены в журналах аудита, полном журнале запросов или CDC?
8. Каковы технические причины превышения времени ожидания или снижения производительности?
9. Соответствуют ли правила резервного копирования и сверки реплик заданным требованиям?
10. Полностью ли перенесены схема и данные по указанным диапазонам токенов?

Результат и стоимость

Специалист фиксирует устройство кластера и исходные объекты, проверяет контрольные суммы, анализирует копии SSTable и журналов фиксации в автономной среде, восстанавливает копию на изолированном кластере, сопоставляет журналы и проверяет альтернативные объяснения. Результатом может быть консультация, внесудебное исследование, судебная экспертиза или рецензия. Ориентир по стоимости — от 100 000 ₽, срок — от 10 рабочих дней; на них влияют число узлов и диапазонов, объём, версия, шифрование, состояние сверки реплик и поставленные вопросы. Если судебная экспертиза уже назначена, назначенный по делу эксперт не принимает от одной стороны напрямую дополнительные снимки узлов, выгрузки и системные журналы и не даёт ей частную оценку по существу поручения: вопросы, доступ и новые материалы идут через назначивший орган. Это не исключает обращения стороны к другому, не назначенному по делу специалисту — за консультацией или рецензией по законно полученным материалам. Готовое заключение проверяют в рамках рецензии на заключение экспертизы баз данных и СУБД.