i
В жепу HA на урвоне вм
Вот не надо тут, он имеет raison d'etre
Size: a a a
2020 December 14
🍺N
ну я думаю что по бд в интернете много информации буду изучать)
Если в БД большая нагрузка на запись - то в традиционных РСУБД решение скорее всего будет всё же на уровне приложения, т.н. sharding.
АД
🍺 Ilya Nicolaev
Если в БД большая нагрузка на запись - то в традиционных РСУБД решение скорее всего будет всё же на уровне приложения, т.н. sharding.
спасибо, почитаю
🍺N
Ну у того же прокса есть ha-manager с фенсингом на вотчдогах, заюзав DRBD, в принципе с даунтаймом в пару минут можно вполне отказоусточивый сетап органищвать
РСУБД очень не любят, когда у них более одной ноды на запись работают... Причем не любят настолько, что даже падают до невосстановимого состояния
k
🍺 Ilya Nicolaev
РСУБД очень не любят, когда у них более одной ноды на запись работают... Причем не любят настолько, что даже падают до невосстановимого состояния
Зачем на запись-то больше одной?
🍺N
Зачем на запись-то больше одной?
Ну на чтение тоже. Постгрес точно не любит. Для этого репликации уровня СУБД и сделаны. Т.к. нельзя просто так взять, и запустить второй инстанс БД на второй ноде даже на чтение, даже если ФС, на которой эта БД лежит реплицируется на уровне Block Device.
🍺N
HA на СУБД - это задача СУБД
N
оно все на вмваре) если вы о моем вопросе
FT включите на уровне платформы :)
АД
FT включите на уровне платформы :)
что это FT?оО
N
Или если простой в сколько-то минут - не катастрофа, то оставьте HA и ВМ с СУБД просто перезапустится
k
🍺 Ilya Nicolaev
Ну на чтение тоже. Постгрес точно не любит. Для этого репликации уровня СУБД и сделаны. Т.к. нельзя просто так взять, и запустить второй инстанс БД на второй ноде даже на чтение, даже если ФС, на которой эта БД лежит реплицируется на уровне Block Device.
Ну я про то чтобы иметь один инстанс бд на шаред сторадже и в случае отвала ноды просто мигрировать его на другую
АД
Или если простой в сколько-то минут - не катастрофа, то оставьте HA и ВМ с СУБД просто перезапустится
ну изначально задача стояла чтоб без простоев, но если она не реализуема то уже как есть)
🍺N
Ну я про то чтобы иметь один инстанс бд на шаред сторадже и в случае отвала ноды просто мигрировать его на другую
Ну если инстанс болтается как резервный, и вообще никак не задействован - вариант конечно, но я сторонник решений, чтобы реплики работали как минимум в RO-режиме
АД
о, даже не думал об этом, спасибо, тоже изучу
N
ну изначально задача стояла чтоб без простоев, но если она не реализуема то уже как есть)
На FT теряется не более 1-2 пингов
k
что это FT?оО
Fault tolerance?
АД
Fault tolerance?
да)
АД
На FT теряется не более 1-2 пингов
ну это я думаю допустимо будет
N
У вас ничего быстрее не будет - даже на уровне реплик СУБД не переключится быстрее