Есть ИС1 и ИС2.
В обеих системах существует сущность (таблица), допустим "Платежи", при этом в ИС1 платежи загружаются оператором, а в ИС2 они загружаются процедурой синхронизации из ИС1.

Для исключения дублирования платежей в ИС2 фиксируются ID платежа, присвоенного ему в ИС1. При синхронизации платежей из ИС1 в ИС2 проверяется наличие ID платежа в ИС2 и, если есть платеж обновляется, если нет - добавляется.

Теперь проблема.

Регламент резервного копирования ИС1 и ИС2 разный, ИС1 в один прекрасный момент "падает" и админы начинают процедуру восстановления из резервной копии ИС1 за несколько дней назад. При этом ИС2 не откатывается на ту же дату.

После этого пользователи ИС1 начинают загружать платежи но они регистрируются в ИС1 с НОВЫМИ идентификаторами, которые при последующей процедуре синхронизации попадают на ранее синхронизированные (после последнего бэкапа до падения ИС1) идентификаторы и ОБНОВЛЯЮТ ранее загр. платежи в ИС2, но т.к. порядок повторной загрузки платежей скорее всего не совпадет то за дни с даты падения ИС1 и даты восстановления из бэкапа получится мешанина.

Хочу найти принципиальное решение как обеспечить поддержку целостности между двумя системами в случае сбоя и отката источника назад.
Самый простой вариант - при сбое ИС1 откатывать назад ИС1 и ИС2 вместе, даже несмотря на то что ИС2 функционирует нормально. Минус этого решения очевиден - потеря работы пользователей не только ИС1 но и пользователей ИС2.

Какие могут быть варианты?

Mainframe_старыйiscrafmRus000
Какие могут быть варианты?
вариант очевиден - зеркальное отображение данных, производимых системой ИС1 в системе ИС2.

p.s. ну и конечно избавить, по возможности, систему от "падений", а то об этом говорится как о стандартной ситуации.
зеркалирование поможет, если в ИС2 не было ссылок (прямых) на сущность, залитую из ИС1. В противном случае, зеркалирование не спасет от ситуации, когда источник откатили на несколько дней, а в ИС2 уже к тем данным, что введены за последние несколько дней уже есть привязка.


ситуация именно такая - залитые из ИС1 платежи участвуют в других процессах ИС2 и это осложняет поиск решения без потери сделанной работы пользователями ИС2

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


поясните мысль подробнее - у платежа стандарно есть несколько реквизитов, композицию которых можно конечно рассматривать как уникальный ID, но не будет ли это дорого стоить с точки зрения хранения и использования?

iscrafmMainframe_старыйзеркалирование поможет, если в ИС2 не было ссылок (прямых) на сущность, залитую из ИС1. В противном случае, зеркалирование не спасет от ситуации, когда источник откатили на несколько дней, а в ИС2 уже к тем данным, что введены за последние несколько дней уже есть привязка.
если привязка есть, значит имел место факт платежа. Есть системы, которые синхронизируются при помощи механизмов зеркального отображения. Если одну, по какой-то причине откатили, то точно также можно и "накатить", естественно. Но опять же, повторюсь: рассматривается какой-то абстрактный пример, исключительная ситуация.

ИС1 и ИС2 не являются зеркалами друг к другу. Они реализованы на разных платформах и имеют разный функционал. Все что их объединяет - это платежи которые нужны для самостоятельного учета в каждой из систем. Платежи поступают по цепочке Казначейство->ИС1->ИС2

Сейчас думаю над вариантом разбиения цепи на две
Казначейство->ИС1
Казначейство->ИС2

iscrafmНо опять же, повторюсь: рассматривается какой-то абстрактный пример, исключительная ситуация.

К сожалению пример не абстрактный а из жизни. Следить за отказоустойчивостью более 80 пар ИС1-ИС2 затруднительно, а техника и новые сырые версии ИС1 могут ломать шаткое равновесие.

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

Соглашусь, даже в классической двунаправленной синхронизации есть геморрой под назнание разрешение конфликтов. В нашем случае ИС1 и ИС2 не зеркала априори.

egorychRus000Регламент резервного копирования ИС1 и ИС2 разный, ИС1 в один прекрасный момент "падает" и админы начинают процедуру восстановления из резервной копии ИС1 за несколько дней назад. вообще говоря, что это за регламент резервного копирования такой, что при падении приходится восстанавливать систему с потерей нескольких дней? менять надо такой регламент скорее, и это не имхо, а первейшая необходимость.

согласен, это одна из мер только из разряда организационных.
Но все равно даже если резервное копирование ежедневное, откат ИС1 на день назад повлечет откат на день работы совершенно нормально работающей ИС2.

Возможно это жертва которую придется принести за связывание одной сущности в двух ИС

alexeyvgRus000Хочу найти принципиальное решение как обеспечить поддержку целостности между двумя системами в случае сбоя и отката источника назад.
...
Какие могут быть варианты?Принципиальное решение - создавать идентификатор платежа до регистриции в ИС1, по файту появления желания сделать платёж.

Далее всё, что связано с этим платежём - регистрация в ИС1...ИСн, текстовые логи в терминалах, стикеры, наклееные на мониторах - должны идти с этим идентификатором.

Вариант этого решения - предложение Mainframe_старый.


Вы об этом?

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

согласен и с первым со вторым, поэтому и ищу решение.
Наиболее правильным видимо будет отказаться от синхронизации и задублировать входящий платежей на обе системы.

egorychRus000Но все равно даже если резервное копирование ежедневное, откат ИС1 на день назад...современные промышленные СУБД давно уже умеют восстанавливать базу на момент сбоя, при правильно организованной схеме резервного копирования. Чтение документации и правильные вопросы на профильном форуме по вашей СУБД помогут вам в определении таковой.


Вы о чем, коллега? любому здесь понятно что СУБД умеют восстанавливать данные на момент сбоя, но как это относится к описанной ситуации? в данному случае непротиворечивая резервная копия есть совокупность резервных копий ИС1 и ИС2 при условии что регламентной синхронизации не произошло.
В противном случае Вы не можете быть застрахованы от сбоя в любом звене, и все регламенты летят к черту. Или приведите здесь "правильно организованный регламент" для описанной ситуации.

egorych
Имхо, вам надо направить свои усилия на повышение отказоустойчивости системы ИС1, вместо изобретения странных костылей. Принципы построения отказоустойчивых систем известны и давно опубликованы, и включают как программные, так и административные методы.

Хм .. Вы же понимаете, что повышение процента отказоустойчивости ИС1 никогда не достигнет 100%, причем каждый процент после 80-90 Вам будет стоить в как первые 90.
Таким образом резервная копия ВСЕГДА будет одним из инструментов повышения отказоустойчивости, а раз так существует ситуации когда ИС1 сбойнет и потребуется восстановление данных. Хороший пример - кривая версия ПО, когда требуется экстренный откат обратно.

Может изложите что-то по существу вопроса вместо общих всем известных сентенций

iscrafmRus000,

речь идет о системах, над которыми Вы не имеете контроля? т.е. это закрытое ПО, чьего-то производства?

должный контроль только над ИС2, над ИС1 только косвенный

iscrafmRus000,

речь идет о системах, над которыми Вы не имеете контроля? т.е. это закрытое ПО, чьего-то производства?

ИС1 разработана другим исполнителем и доступна только как источник данных, изменять код ИС1 не представляется возможным в краткосрочной перспективе

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

Вариант может и надежный но для описанной ситуации на мой взгляд мало применимый
1) ИС1 и ИС2 имеют разных разработчиков
2) синхронизация платежей односторонняя и в обратном течении потока нет смысла
3) даже если бы мы начали думать над п.2) то придется брать ответственность за корректную вставку данных в чужое ПО (минуя интерфейс пользователя), а этого никому не хочется.

guest_20040621> мы используем - семантическую привязку

Какая бы это была привязка, например для казначейского платежа так чтобы ключ связи был уникальным?

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

guest_20040621
Для внешних источников imho удобно поддерживать промежуточную базу данных.

Правильно я понял, что Вы предлагаете добавить ИС0 которая будет назначать идетификаторы платежам, а потом из нее мы грузим независимо в ИС1 и ИС2?

Если так, то какая гарантия, что с ИС0 не случится сбой/восстановление? В итоге придем к началу.

egorych[Уже понятно, что контроля над кодом ИС1 у вас нет, однако: администрирование этой системы находится в ваших руках? есть ли возможность развернуть тестовую версию этой системы?

Администрирование можно управлять только посредством корректировки регламентов, потому как кол-во пар ИС1-ИС2 более 80 (регионы)

Тестовую версию ИС1 конечно можно развернуть, только вопрос что это дает?

iscrafmRus000iscrafmRus000,

речь идет о системах, над которыми Вы не имеете контроля? т.е. это закрытое ПО, чьего-то производства?

ИС1 разработана другим исполнителем и доступна только как источник данных, изменять код ИС1 не представляется возможным в краткосрочной перспективе
понятно. Тогда в ИС2 придется напрямую получать первичную информацию из казначейства. Если конечно есть такая возможность.

да, такой вариант возможен но придется серьезно переписывать блок приема платежей, а это время и ресурсы. Пока рассматриваю его как наиболее правильно но крайний вариант

Mainframe_старыйRus000
Какая бы это была привязка, например для казначейского платежа так чтобы ключ связи был уникальным?

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


Это не для всех сущностей проходит, но для многих. Например, студентов мы гоняем.. не по первичному ключу,а по паспорту+дата рождения.

в моей практике например встречались полные двойники с совпадающими ФИО, датой рождения и местом рождения, так чта .... тут надо осторожнее