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