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