мои фантазии на тему репликации и зеркалировании БД

Методы, механизмы и инструментарий для репликации

Модератор: kdv

Ответить
SeventhSon
Сообщения: 25
Зарегистрирован: 11 авг 2007, 17:40

мои фантазии на тему репликации и зеркалировании БД

Сообщение SeventhSon » 04 окт 2011, 03:27

Опыта у меня мало конечно.Поэтому если моё предложение покажется глупым просьба матом не ругаться а высказываться по существу.
Немного почитал о репликации.Всё сводится к тому чтобы прицепиться к двум готовым базам и начать реплицировать.
Но я не нашёл статей/мыслей о другом, противоположном подходе к репликации.
Почему бы постараться не допускать рассинхронизации работающих баз изначально?
На уровне приложения это делается так. приложение поддерживает два коннекта к двум разным базам-основной и зеркалу.
При insert/update/delete в основную базу данные пишутся сразу а в зеркало-в фоновом процессе с логгированием.
Ну примерно так-при пропадании коннекта операторы SQL пишутся в текстовый файл и при появлении коннекта применяются в той же последовательности. Разумеется программа может сигнализировать пользователю светофором о состоянии зеркала,
красный-зеркало отвалилось,зелёный-всё в порядке, жёлтый-коннект есть, но заливаются данные.
Может быть и разработчики FB сделают такую функцию, в конфиге прописывается путь к исполняемому файлу который вызывается при каждой операции изменения базы и ему передаётся оператор SQL в текстовом виде. А что делать будет решать уже прикладной программист. Хочешь-заливай данные по зеркалам,хочешь пиши лог, а заливать будет отдельный процесс.
Плюс такого подхода-только сервер знает когда данные изменяются в базе, select'ы можно игнорировать, а это минимум нагрузки на сервер и минимум сетевого трафика. Так же это даст больше свободы разработчикам прикладных программ.
Конечно вызов стороннего процесса при каждом изменении базы может сильно повлиять на производительность и даже положить сервер.Но пусть оценивает риск и решает что делать сам админ БД и программист.
Что думаете по этому поводу?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение kdv » 04 окт 2011, 11:21

в приложении делайте что угодно, но разработчики ФБ тут ни при чем.
в конфиге прописывается путь к исполняемому файлу который вызывается при каждой операции изменения базы и ему передаётся оператор SQL в текстовом виде.
вы про аудит и trace api в 2.5 смотрели? Представляете себе, с какой интенсивностью могут идти запросы в системе?
И, если приложение "реплицирует" изменения, то при чем тут сам сервер?
Но пусть оценивает риск и решает что делать сам админ БД и программист.
см. выше. но все равно imho это фигня. Но вы можете реализовать эту идею прямо сейчас.

SeventhSon
Сообщения: 25
Зарегистрирован: 11 авг 2007, 17:40

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение SeventhSon » 04 окт 2011, 12:36

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение kdv » 04 окт 2011, 15:37

как бы само собой разумеется что лучше всего именно серверу видно когда идёт изменение таблиц.
в 2.5 сервер об этом может сообщить через Trace API. Но может возникнуть такая ситуация, что если приложение не успевает получать от Trace API информацию, то сервер продолжает работать, таким образом часть информации о выполняемых на сервере операторах может быть потеряна (между сервером и приложением).
Дальше. update может быть в 13:00, а commit - в 14:00. Значит ваше приложение (а не сервер) должно ЗАПОМНИТЬ update, и ждать, чем завершится транзакция.
механизм репликации выгоднее всего именно в сервер
выгоднее, но его нет, и вряд ли будет (потому что механизмы тиражирования (а не репликации) в других серверах реализованы обычно через распространение логов транзакций).
разве сторонняя программа репликации не увеличивает интенсивность запросов?
тогда вы плохо прочитали про репликацию. В любой базе, как правило, реплицируется вовсе не абсолютно все изменения, а только те, которые сохранены по commit, и более того, которые "финализированы". например, был insert, потом 5 update одной записи. Зачем "реплицировать" все эти операторы? Достаточно реплицировать insert с конечными значениями столбцов. Или, добавьте туда же delete в конец - реплицировать вообще ничего не придется.
В общем, "онлайновая репликация" - плохо.
как раз речь о том что если сам сервер будет сигнилизировать об изменениях в базе вызовом чего-то это минимизирует нагрузку на сервер
вы, как я понял, даже после моего ответа не посмотрели ничего про Trace API (включая вебинар), и фантазируете.

SeventhSon
Сообщения: 25
Зарегистрирован: 11 авг 2007, 17:40

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение SeventhSon » 04 окт 2011, 17:38

вот я о том и говорю. выдавать в лог комиченую транзакцию серверу проще. он точно знает что и когда комитится.
про trace api читаю пока.про 5 апдейтов это спорные нюансы.если это человеческий фактор то эта проблема уходит в другую плоскость.нет смысла её обсуждать.
склоняюсь к мысли что создавать в приложении нужное количество коннектов к зеркальным базам пока единственный вариант

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение kdv » 04 окт 2011, 23:35

про 5 апдейтов это спорные нюансы.если это человеческий фактор то эта проблема уходит в другую плоскость.
ну какая, нафиг, плоскость?
создавать в приложении нужное количество коннектов к зеркальным базам пока единственный вариант
я еще раз спрошу - что если один из серверов будет в какой-то момент недоступен (N секунд)?

SeventhSon
Сообщения: 25
Зарегистрирован: 11 авг 2007, 17:40

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение SeventhSon » 05 окт 2011, 04:01

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

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение Dimitry Sibiryakov » 05 окт 2011, 15:17

kdv писал(а):выгоднее, но его нет, и вряд ли будет
А вот этот момент мне бы и хотелось выяснить в Люксембурге. Потому что заказчик нервничает и настаивает чтобы ответные меры были приняты заранее.
kdv писал(а):например, был insert, потом 5 update одной записи. Зачем "реплицировать" все эти операторы? Достаточно реплицировать insert с конечными значениями столбцов.
Не всегда. Ой, не всегда... Иные архитекторы приложений такого понаворачивают, что этот клубок змей лучше не трогать.

SeventhSon
Сообщения: 25
Зарегистрирован: 11 авг 2007, 17:40

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение SeventhSon » 05 окт 2011, 16:00

Иные архитекторы приложений такого понаворачивают
имхо сервер и разработчиков это вообще волновать не должно. делает программер 5 апдейтов-его проблемы. пусть его начальник за это ругает.
рассуждая в таком ключе можно придти к необходимости встраивания антивирусного сканера для блобов например.
приборы для чтения мыслей пока не изобрели.тут всё просто-если транзакция подтверждена её надо логгировать/зеркалировать.а то что после insert ещё 5 раз update и 1 delete это другой вопрос который к репликации не имеет отношения.это вопрос производительности и оптимальности кода.
можно ведь в сервере реализовать функцию, суть работы которой состоит в записи подтверждённой транзакции в лог?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение kdv » 06 окт 2011, 14:48

делает программер 5 апдейтов-его проблемы.
я имел в виду приложение и пользователя. Обработка данных может быть любой по сложности.
рассуждая в таком ключе можно придти к необходимости встраивания антивирусного сканера для блобов например.
гм, по-моему, это вы предлагаете чтобы сервер занимался зеркалированием-репликацией, а не я.
можно ведь в сервере реализовать функцию, суть работы которой состоит в записи подтверждённой транзакции в лог?
нет. я еще раз повторю. update сейчас, и commit через час. Сервер, конечно, в savepoints помнит изменения, сделанные в транзакции, но не всегда (если больше 50к изменений - сбрасывает на диск и забывает).
insert ещё 5 раз update и 1 delete это другой вопрос который к репликации не имеет отношения.
это вопрос, который имеет абсолютно прямое отношение к репликации. Программные репликаторы, существующие сегодня, как раз позволяют настроить - какие действия над какими таблицами реплицировать, и как реплицировать.
Вместо этого вы предлагаете тупое онлайновое распространение sql на "зеркальную" базу. При этом, работа двух пользователей с этими базами не будет отличаться ничем от работы двух пользователей с ОДНОЙ базой. И, между базами должен быть достаточно быстрый и надежный канал. А раз так, то никакого смысла "зеркалировать" изменения во вторую базу нет - пользователи, работающие со базой Б, могут точно так же работать с первой.
Пример - база А, "зеркалируется" в базу Б. С базой А работают 10 пользователей, с базой Б - 5. Между базами получается поток информации, равный интенсивности работы 15-ти пользователей. При этом, если какой-то пользователь редактирует запись в базе А, в базе Б эта запись точно так же блокируется. И, в этом случае, при любой "рассинхронизации" одна из баз должна быть блокирована, пока связь между БД не восстановится.
Кстати, не знаю, почему мне приходится объяснять это тому, кто придумал эту схему. И вообще это получается не репликация, а "распределенная БД".

Вопросы надежности самой базы решаются несколько иными способами. например raid, nbackup...

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: мои фантазии на тему репликации и зеркалировании БД

Сообщение kdv » 06 окт 2011, 14:50

И повторю еще раз - сейчас в ФБ 2.5 есть Trace API. Если вам нужна подобная "репликация", то вы ее можете написать прямо сейчас, самостоятельно.

Ответить