Вы можете регулярно проверять, происходят ли изменения данных, хотя это может быть сложно в зависимости от вашего приложения.
Если у вас есть какая-то форма таблицы аудита, которая регулярно обновляется (т. Е. У нашего основного продукта есть базовая таблица аудита, в которой перечислены все действия, которые приводят к обновлению или удалению данных), вы можете запросить эту таблицу на обоих серверах и убедитесь, что вы получите тот же результат. Что-то вроде:
SELECT CHECKSUM_AGG(*)
FROM audit_base
WHERE action_timestamp BETWEEN <time1> AND BETWEEN <time2>
где и - округленные значения, чтобы учесть различные задержки при обращении к базам данных. Например, если вы проверяете в 10 часов утра, вы можете проверять позиции с начала последнего часа до начала этого часа. Теперь у вас есть два небольших значения, которые вы можете где-то передать и сравнить. Если они различаются, то, скорее всего, что-то пошло не так в процессе репликации - при любом процессе проверки / сравнения отправит вам письмо и SMS, чтобы вы могли проверить и исправить любую проблему, требующую внимания.
При использовании SELECT CHECKSUM_AGG (*) объем данных для каждой таблицы очень очень мал, поэтому использование проверок пропускной способностью будет незначительным. Вам просто нужно убедиться, что ваши чеки не слишком дороги в нагрузке, относящейся к серверам, и что вы не проверяете данные, которые могут быть частью транзакций открытой репликации, поэтому в этот момент можно ожидать, что они будут другими (следовательно, проверка контрольный журнал несколько минут назад, а не в моем примере), иначе вы получите слишком много ложных сигналов тревоги.
В зависимости от структуры вашей базы данных вышеприведенное может быть нецелесообразным. Для таблиц, которые не предназначены только для вставки (без обновлений и удалений) в течение периода вашей проверки (например, контрольный журнал, как указано выше), определение того, что можно безопасно сравнить, избегая ложных сигналов тревоги, может оказаться сложным и дорогостоящим, если на самом деле невозможно сделать надежно.
Можно создать скользящую таблицу только для вставки, если у вас ее еще нет, имея небольшую таблицу (содержащую только столбец с индексированной отметкой времени), к которой вы регулярно добавляете одну строку - эти данные не служат никакой цели, кроме существования так что вы можете проверить, обновляются ли таблицы. Вы можете удалить данные старше вашего контрольного окна, поэтому таблица не должна увеличиваться в размерах. Только проверка одной таблицы не доказывает, что все другие таблицы реплицируются (или любые другие таблицы в этом отношении), но обнаружение ошибки в этой одной таблице было бы хорошей проверкой "canery" (если эта таблица не обновляется в реплике, тогда другие, вероятно, тоже не обновляются).
Преимущество такого рода проверок заключается в том, что они не зависят от процесса репликации - вы не ожидаете, пока процесс репликации запишет исключения в журналах, вместо этого вы активно тестируете некоторые фактические данные.