Записки автоматизатора. Профессиональная исповедь

Орлов Андрей Юрьевич

Рис. 9. Пример распределенной системы с асинхронными репликациями

Такие системы называются системами с асинхронными репликациями, а сам комплект изменений, за один раз передаваемый от одной локальной базы к другой, – репликой. Те, кому не нравится импортное слово «репликация», используют слово «тиражирование», которое почему-то считают более русским. На мой взгляд, больше подходит «выравнивание», но не хочется путать читателя еще больше.

Механизмы

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

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

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

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

Очень интересно получится, когда сервера системы начнут функционировать в разных часовых поясах. Конечно, СУБД при репликации позаботится о модификации временных меток, которые она сама установила, но как работать с другими датами и временами, записанными в базе, вам было бы неплохо заранее разобраться самому, чтобы потом не гадать, глядя на 0:00, была в этот момент полночь в Москве или в Петропавловске-Камчатском.

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

Пример. Пусть по каким-то причинам вы храните фамилию в одной таблице базы, а имя и отчество – в другой, ссылающейся на первую. В Урюпинске оператор заполнил форму, в которой указал Орлв Андрей Георгиевич. С помощью репликаций эта информация должна оказаться в Арзамасе. Реплики отправляются по расписанию, объем одной реплики ограничен. Поэтому в Арзамас в первой реплике пришла только фамилия из главной таблицы. Оператор в Арзамасе увидел ошибку в фамилии и исправил ее. Теперь в Арзамасе в главной таблице «Орлов», а в зависимой еще пусто. Наконец со следующей репликой в Арзамас приходит запись, в которой указано «Андрей Георгиевич». Но в базу она не попадет: главная запись уже была изменена, и процедура автоматического разрешения коллизий «Андрея Георгиевича» отвергнет.

Если же вы еще и не все зависимости описали на уровне СУБД, а поддерживаете какие-то из них с помощью алгоритмов обработки, то становится совсем загадочным, как это все собрать на принимающем конце.

А поскольку многие системы стараются поддерживать несколько СУБД, то вероятность использования механизмов приложения, а не СУБД в них достаточно велика, что делает репликацию средствами СУБД достаточно сложной. – Д. К.

Арсенал средств обработки в современных СУБД весьма внушителен, все они полезны в каких-то случаях, но желание разработчика использовать все эти средства сразу может приводить к результатам слабо предсказуемым. А ведь часто данные в нескольких зависимых записях сначала изменяются хранимой

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

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

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

Коллизия – это в любом случае плохо. Разрешение коллизии, каким бы способом оно ни производилось (по времени изменения записи, по приоритету площадки или пользователя, администратором системы вручную после необходимых телефонных звонков), означает, что вы похоронили чью-то работу.

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

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

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

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

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

Очень жаль, что в техническом задании не принято писать «Программа должна работать»…

Единственный общий совет этого раздела: старайтесь не экономить время на этапе постановки (написания технического задания). Реально это единственный этап, на котором время вам выделено именно для того, чтобы вы думали – дальше нужно будет трясти. Правда, руководство и на этом этапе требует сверхскоростей. Ведь для него хуже нет, чем вот уже два месяца платить зарплату и не иметь с этого не только никакого барыша, но даже хотя бы какого-то видимого результата. Однажды на очередной покрик «Давай-давай!!!» я отыскал в Интернете, распечатал и раздал всем генерально-исполнительным начало первой главы «Винни-Пуха»: