Со всеми оптимизациями?

С некоторыми оптимизациями

для кого валидно? где? если вы будете класть БД в проде на 15 минут в неделю - это не фига не валидно...

Все это проводится на бекэнде. Фронтэнд не страдает

Все это проводится на бекэнде. Фронтэнд не страдает

такого понятия нет у БД

админы подняли железо, софт сам поднялся

На новом сервере? Скрипты поднятия тоже 100% рабочие?

Ну чем он плох

Если одним словом, то подходом, из чего и растет все остальное. Если мы пошлем еще пару запросов на реплики, то все отреплицируется и за этим не надо следить, если ФС не упадет, то fsync делать не нужно, если я не видел никогда больших данных и параллельной обработки запросов, то однопоточный ивент луп сойдет, если не видел возможности переписать конфигом authorized_keys, то никто этого делать не будет.

На новом сервере? Скрипты поднятия тоже 100% рабочие?

виртуалка же ?

такого понятия нет у БД

Там физически разные БД и разные структуры

такого понятия нет у БД

Hidden реплика обычно всегда есть

виртуалка же ?

Ок, новая виртуалка, не суть

Ок, новая виртуалка, не суть

зачем мне новая виртуалка, если есть существующая? о_0

Hidden реплика обычно всегда есть

но это не backend

зачем мне новая виртуалка, если есть существующая? о_0

Сдох гипервизор, умер диск, еще что-то

почитайте, что такое backend

Сдох гипервизор, умер диск, еще что-то

бэкап виртуалки отменяли?

бэкап виртуалки отменяли?

В бекапе старые данные, восстановление из бекапа тоже 100% рабочее?

надо уже заканчивать мне с этим юмором

В бекапе старые данные, восстановление из бекапа тоже 100% рабочее?

в виртуалке нет данных - там нода, данные на отдельной железке, в которой отдельный бэкап

в виртуалке нет данных - там нода, данные на отдельной железке, в которой отдельный бэкап

Ок, я уже понял, что у вас все обложено автоматикой, которая 100% рабочая и вероятности сбоя нигде не существует.

она есть, но я не вижу проблемы, где не справится штатный админ или я, как разработчик

Если это надо запускать раз в сутки или даже в неделю, то проще запускать на том что есть, чем убить квартал разработки для переноса статистики в вертику. Сервер дешевле программиста.

Ну вот поднял ты вертику и даже перенес в не статистику. Ушёл в отпуск. Кто будет разбираться почему вдруг база перестала работать?

дубль два?

Ну ответа я не получил)

а с чего она вдруг перестала работать?

сливаются таблицы один к одному и сливаются

железо не моя забота, на то есть админы

софт поднимается нормально и сам

как раз на НГ упали сервера

вот вообще было пофиг мне

админы подняли железо, софт сам поднялся

чем не ответ

Если одним словом, то подходом, из чего и растет все остальное. Если мы пошлем еще пару запросов на реплики, то все отреплицируется и за этим не надо следить, если ФС не упадет, то fsync делать не нужно, если я не видел никогда больших данных и параллельной обработки запросов, то однопоточный ивент луп сойдет, если не видел возможности переписать конфигом authorized_keys, то никто этого делать не будет.

Гм, у меня всегда было отношение к редису как к более умному и гибкому memcached. Репликация там есть, но я бы никогда её не стал использовать. А persistent данные вообще отключать.

чем не ответ

Тем, что есть куча вероятности, когда автоматика не отработает и все не поднимется. Особенно когда вся инфраструктура на postgre/mysql/oracle, а вертика где-то сбоку на коленке поднята.

Угу, единственное, на что он способен - это деревянный кэш. А для этого есть и более интересные решения, не замыкающиеся на ивент лупе, знающие, что такое таймаут и автоматом реплицирующиеся/шардящиеся, чтобы при необходимости увеличения кластера это не вызывало головной боли.

Тем, что есть куча вероятности, когда автоматика не отработает и все не поднимется. Особенно когда вся инфраструктура на postgre/mysql/oracle, а вертика где-то сбоку на коленке поднята.

мне прям стало интересно, почему не поднимется

Его можно рассматривать только в качестве штуки, которую можно в случае чего выбросить и не волноваться. А зачем она тогда вообще - хз.

прям так и вижу - ребут сервера, ничего не поднялось, бегаем по кругу с криками "А-А-А-А-А-А-А"

Тем, что есть куча вероятности, когда автоматика не отработает и все не поднимется. Особенно когда вся инфраструктура на postgre/mysql/oracle, а вертика где-то сбоку на коленке поднята.

Ну так что, хотя бы пример будет, почему не поднимется?

Ну так что, хотя бы пример будет, почему не поднимется?

гайзенбаг? =)

гайзенбаг? =)

Переведи

или просто не до конца отлаженный скрипт для неосновной базы данных

Переведи

https://ru.wikipedia.org/wiki/%D0%93%D0%B5%D0%B9%D0%B7%D0%B5%D0%BD%D0%B1%D0%B0%D0%B3

или просто не до конца отлаженный скрипт для неосновной базы данных

Это бред, тесты есть

Это бред, тесты есть

все покрыто тестами с coverage = 100% ?

https://ru.wikipedia.org/wiki/%D0%93%D0%B5%D0%B9%D0%B7%D0%B5%D0%BD%D0%B1%D0%B0%D0%B3

Не тот вариант, ибо с данными не работаем

Не тот вариант, ибо с данными не работаем

причём тут данные? оно может проявиться в любом месте: в скрипте поднятия из резервной копии, например

все покрыто тестами с coverage = 100% ?

А в чем проблема? Ошибки могут быть, только если в проде начали менять типы данных, да и то, это можно автоматом регулировать

причём тут данные? оно может проявиться в любом месте: в скрипте поднятия из резервной копии, например

Т.е. вы априори закладываете ошибки поднятия сервера по причини софта?

А в чем проблема? Ошибки могут быть, только если в проде начали менять типы данных, да и то, это можно автоматом регулировать

edge case

Вы там свои БД что-ли пишите

Т.е. вы априори закладываете ошибки поднятия сервера по причини софта?

мы перешли на "вы"? ок, а Вы считаете все системы 100% надёжными что ли? я вот на этот вопрос ответ не понял.

возьмем классику с js

бэкенд-приложение отдает int64

в тестах используются числа "один", "два" и "два миллиарда"

на проде приходит переполнение

мы перешли на "вы"? ок, а Вы считаете все системы 100% надёжными что ли? я вот на этот вопрос ответ не понял.

Можно на ты, я не против, пардон, если двояко пишу. Я считаю, что ошибки перегона данных из одной БД в другую полностью автоматизированы

возьмем классику с js

Мы сейчас говорим не про общение софта с БД, а перегон данных между двумя БД

Если в одной БД инт64, то не составит проблем перегнать в другую с инт64

ты сейчас явно не корректность отстаиваешь

если в одной бд 64, в другой 64, а перекатывает это все из одной в другую js, то вот тебе опять переполнение

и проблема не в том, что я пишу неприменимый пример, а в том, что ты отказываешь в существовании целой плеяды багов, которые неочевидны

если в одной бд 64, в другой 64, а перекатывает это все из одной в другую js, то вот тебе опять переполнение

Это при условии, что перегонщик лезет в данные, но по факту он не лезет

чиво

он бинарным потоком пересылает?

Представь импорт экспорт csv например

ERROR: S client not available

Пофиг на данные, они есть и все

угу, и в csv блобы

например

Можно на ты, я не против, пардон, если двояко пишу. Я считаю, что ошибки перегона данных из одной БД в другую полностью автоматизированы

Мигрировать данные из одной базы в другую - вопрос не тривиальный, особенно если вдруг промзошёл где-то сбой, копию откатили, а сётчик на основной базе, отдающий дифф, - забыли или ещё что-то: тут можно кучу примеров придумать, даже где на стыке могут быть проблемы. И отсюда изначальный вопрос, заданный где-то час назад: зачем убивать на это всё время, русурсы разработчиков, админов, тестировщиков, если можно поднять ещё одну реплику для аналитики той же БД, которая уже используется и к которой все привыкли и собирать статистику оттуда, даже если она будет работать полчаса, а не 30 секунд? Если это выполняется реже, чем раз в те же сутки - зачем?

угу, и в csv блобы

Даже если есть блобы, хотя на них мир не сошелся и это не самый распространенный формат, то я не вижу проблем перегонять и их

в csv?

в csv?

Csv я привел для примера, не более

а в чем можно?

Мигрировать данные из одной базы в другую - вопрос не тривиальный, особенно если вдруг промзошёл где-то сбой, копию откатили, а сётчик на основной базе, отдающий дифф, - забыли или ещё что-то: тут можно кучу примеров придумать, даже где на стыке могут быть проблемы. И отсюда изначальный вопрос, заданный где-то час назад: зачем убивать на это всё время, русурсы разработчиков, админов, тестировщиков, если можно поднять ещё одну реплику для аналитики той же БД, которая уже используется и к которой все привыкли и собирать статистику оттуда, даже если она будет работать полчаса, а не 30 секунд? Если это выполняется реже, чем раз в те же сутки - зачем?

Это при условии, что мы тянем дифф данные, если тянуть целиком, то пофиг

а в чем можно?

В потоке

бинарном?

бинарном?

Какой сделаешь

ты не сделаешь бинарный, это же разные базы

Это почему?

потому что у них разный формат

так бывает

когда разные приложения используются

А драйвера для БД отменили что-ли?

а они здесь каким боком?

и если тебе нужен драйвер для бд, то ты автоматом в своем коде разбираешь данные

и мы возвращаемся назад

Драйвера нужны для коннекта

в общем, на все это насрать на самом деле

Это при условии, что мы тянем дифф данные, если тянуть целиком, то пофиг

если тянуть целиком данные, то можно залочить один из слейвов сильно дольше, чем на полчаса + время на трансляцию базы из основной в вертику + время на загрузку данных в ту же вертику и... можно получить не 30 минут на статистику, а несколько часов - легко

меня просто бесит, когда задача переформулируется на ходу и делаются непонятные допущения с единственной целью доказать свою правоту

если тянуть целиком данные, то можно залочить один из слейвов сильно дольше, чем на полчаса + время на трансляцию базы из основной в вертику + время на загрузку данных в ту же вертику и... можно получить не 30 минут на статистику, а несколько часов - легко

Лок на врятли, все таки банальный селект, но проиграть во времени можно, только если все тянуть, но если тянуть только необходимое под запрос, можно выйграть

меня просто бесит, когда задача переформулируется на ходу и делаются непонятные допущения с единственной целью доказать свою правоту

Я не менял задачу

флудеры

Если рассуждать логически, то поднимать реплику ради одного запроса на пол часа - бред, как и перегон данных. Поэтому предполагаем, что в потенциале, таких запросов будет не один, и вот тут как раз уже встает второй вопрос, мы хотим быстро получать данные или пофиг. Если пофиг как, то соглашусь, делайте реплику и крутите запросы на ней

что делать с аналитикой то ?

без реплики ?