ЕО
Я изначально думал, что это ссаный девопс, если честно
Size: a a a
2021 April 16
ЕО
Эдакая самоирония. Но, честно говоря, сейчас человек не кажется склонным к самоиронии
DS
а я ссаньё_девопс прочитал =)
SP
тебе не нужно это
SP
он вроде только две написал и не совсем про кложу...
SP
сейм шит
МS
ну маам
SP
книжки Шульгина и правда можно
МS
они долго держат
AS
вы такие умные все
2021 April 19
PK
Бесплатный вебинар «Все для быстрого старта проекта на Managed-базах данных» от Mail․ru Cloud Solutions
Часто уже на самом старте проекта важно определиться с типом СУБД и учесть нюансы архитектуры решения. Для отдельных компаний важно, чтобы данные оставались неизменными и воспроизводились в первозданном виде, для других проектов нужны БД, которые помогут справиться с периодом пиковых нагрузок.
На вебинаре от MCS вас ждет вводный курс по Managed СУБД: вы получите базовую информацию о работе с облачными базами данных и узнаете, как выбрать инструмент в зависимости от особенностей ИТ-инфраструктуры и специфики задач.
Мероприятие пройдет во вторник, 27 апреля, онлайн.
Начало в 17:00 по Москве.
Бесплатно
Регистрация по ссылке: https://vk.cc/c0Uqyi
Часто уже на самом старте проекта важно определиться с типом СУБД и учесть нюансы архитектуры решения. Для отдельных компаний важно, чтобы данные оставались неизменными и воспроизводились в первозданном виде, для других проектов нужны БД, которые помогут справиться с периодом пиковых нагрузок.
На вебинаре от MCS вас ждет вводный курс по Managed СУБД: вы получите базовую информацию о работе с облачными базами данных и узнаете, как выбрать инструмент в зависимости от особенностей ИТ-инфраструктуры и специфики задач.
Мероприятие пройдет во вторник, 27 апреля, онлайн.
Начало в 17:00 по Москве.
Бесплатно
Регистрация по ссылке: https://vk.cc/c0Uqyi
DS
@sanyo_devops тебя как у DBA хочу спросить
Есть два бэкенда которые пишут данные в одну СУБД (mognodb), но в разные базы. Данные разные, друг от друга не зависят.
Инстанс СУБД это три сервера в replicaSet (в терминах mongo)
Хочу для одного из этих бэкендов поднять отдельный mongodb сервер (отдельный replicaSet) с копией базы и переключить этот бэкенд на него безшовно. То есть просто хочу банально вынести базу на другой replicaSet без простоя и потери данных.
Такие выкрутасы в mysql/postgresql проходят без проблем. Поднимаем реплику, ждем когда догонит. Переключаем бэкенд на реплику PROFIT. Дальше можно отключить репликацию и удалить данные на старой базе.
А вот c mongodb не могу придумать как это сделать без простоя. Пока у меня план такой:
1) Поднять еще один сервер с mongo, и подключить его в текущий replicaSet четвертым участником.
2) Дождаться когда на него прилетят все данные.
3) отключить бэкенд
4) Отключить новый mongo сервер от replicaSet и перевести его в standalone режим
5) Переключить бэкенд на новый mogno сервер и запустить.
6) Удалить данные на старом mongoDB сервере в моем случае это данные из коллекций с полем "backend":2 ну или просто базу данных, если backend имел отдельную базу
По идее других путей у меня нет? Или есть какие-то хитрости, которые позволили бы мне сделать это без отключения бэкенда на время пока поднимем новую базу? Склоняюсь к тому что придется писать свою реализацию репликации, хотя вот либу на go нашел (https://github.com/whhe/mongo-replicator). Но может есть способ по проще?
Есть два бэкенда которые пишут данные в одну СУБД (mognodb), но в разные базы. Данные разные, друг от друга не зависят.
Инстанс СУБД это три сервера в replicaSet (в терминах mongo)
Хочу для одного из этих бэкендов поднять отдельный mongodb сервер (отдельный replicaSet) с копией базы и переключить этот бэкенд на него безшовно. То есть просто хочу банально вынести базу на другой replicaSet без простоя и потери данных.
Такие выкрутасы в mysql/postgresql проходят без проблем. Поднимаем реплику, ждем когда догонит. Переключаем бэкенд на реплику PROFIT. Дальше можно отключить репликацию и удалить данные на старой базе.
А вот c mongodb не могу придумать как это сделать без простоя. Пока у меня план такой:
1) Поднять еще один сервер с mongo, и подключить его в текущий replicaSet четвертым участником.
2) Дождаться когда на него прилетят все данные.
3) отключить бэкенд
4) Отключить новый mongo сервер от replicaSet и перевести его в standalone режим
5) Переключить бэкенд на новый mogno сервер и запустить.
6) Удалить данные на старом mongoDB сервере в моем случае это данные из коллекций с полем "backend":2 ну или просто базу данных, если backend имел отдельную базу
По идее других путей у меня нет? Или есть какие-то хитрости, которые позволили бы мне сделать это без отключения бэкенда на время пока поднимем новую базу? Склоняюсь к тому что придется писать свою реализацию репликации, хотя вот либу на go нашел (https://github.com/whhe/mongo-replicator). Но может есть способ по проще?
DS
опа не нагуглил такого. Пасибо потыкаю
DS
а оно может постоянно реплицировать какое-то время, чтобы пока бэкенды перезапускаются c переключением на новый mongodb, запросы еще работающих бэкендов и пишуших в старый записались и попали на новый?
AS
чатик есть правильный про монгу в телеге