Comments 4
А если нужно обеспечить высокую доступность реляционных баз данных, то лучше сделать это на уровне СУБД. В этом сценарии приветствуется хорошее знание ее ролевой модели. Правильная настройка ролевой модели помогает распределить транзакции перед переключением на реплику БД: какие-то транзакции закоммитить, какие-то откатить.
Можно здесь "на пальцах" пояснить о чем речь ? Ролевая модель это обычно про секурити, да и что за "рапределение транзакий" (и зачем) при переключении на реплику непонятно.
Имеется в виду, что если использовать ролевую модель, помимо безопасности появляется очень простой механизм для приоритизации запросов.
Речь идет о штатном переключении, например для обновлений OS (нештатные — это уже другая история). Перед таким штатным переключением в скрипте появляется возможность текущую нагрузку распределить: "запросы от этих пользователей commit, а вот от этой группы можно и rollback".
Также перед переключением обязательно нужно смотреть нагрузку, иначе можно попасть на долгое переключение, например, когда наполовину выполненный merge долго откатывается обратно.
“А вы точно DBA?” Что спросить у провайдера перед подключением Managed DBaaS