Postgresql 9.3. Master->Slave. DROP TABLE on master, not on slave.
В силу того, что корпоративный блог скончался, а писать хочется, как минимум для того, чтобы кто-то использовал решения, переберемся сюда.
Попалась довольно оригинальная задача.
Суть в том, что из-за количества серверов, которые пишут приходящие реквесты, обычный винт не стал справляться с базой данных.
Решением было сделать экстенсивно - поставить ssd винт. Но, так как с большими ссд плотная борода, то сделали схему, что SSD стал master, который реплицируется с помощью slony на обычный винт. Вся минимизация происходит на мастере, а вся тяжелая аналитика и веб-интерфейсы идут в реплику.
Вроде все хорошо. Короме одного - SSD мелкий и может держать от силы два-три месяца инфы.
Поэтому стоит задача удалять партиции таблиц (да, все большие таблицы партицированы) с мастера, но при этом оставлять их на слэйве.
Пока решение в разработке.
Первоначально две мысли:
1) Тормозить запись в лог перед удалением и после запускать лог
2) Если ничего не удастся, написать скрипт переноса данных в третью базу данных.
Тут правда непонятно, что делать с аналитикой за долгий период и выборку больше, чем за месяц или два, как совмещать базы. Или если копировать в реалтайме, какой будет лаг и насколько это нагрузит сервер.
Попалась довольно оригинальная задача.
Суть в том, что из-за количества серверов, которые пишут приходящие реквесты, обычный винт не стал справляться с базой данных.
Решением было сделать экстенсивно - поставить ssd винт. Но, так как с большими ссд плотная борода, то сделали схему, что SSD стал master, который реплицируется с помощью slony на обычный винт. Вся минимизация происходит на мастере, а вся тяжелая аналитика и веб-интерфейсы идут в реплику.
Вроде все хорошо. Короме одного - SSD мелкий и может держать от силы два-три месяца инфы.
Поэтому стоит задача удалять партиции таблиц (да, все большие таблицы партицированы) с мастера, но при этом оставлять их на слэйве.
Пока решение в разработке.
Первоначально две мысли:
1) Тормозить запись в лог перед удалением и после запускать лог
2) Если ничего не удастся, написать скрипт переноса данных в третью базу данных.
Тут правда непонятно, что делать с аналитикой за долгий период и выборку больше, чем за месяц или два, как совмещать базы. Или если копировать в реалтайме, какой будет лаг и насколько это нагрузит сервер.