Надо отдать должное NetApp — у них получился действительно инженерный шедевр, от железа до метрик. Вот только стоимость их решений доступна лишь очень жирным котам. Революционность ZFS в том, что Sun взяли годные идеи NetApp, и переписали их, избегая запатентованных технологий, и открыли исходники. Как-то давно примерно так поступил Торвальдс и GNU.
Так что скажем спасибо IBM за многомилионные мейнфреймы, благодаря которым у каждого есть дешевые компьютеры, скажем спасибо NetApp, что их разработки, окупившись в энтерпрайзе, пошли «в народ», и скажем «спасибо» Ораклу, похоронившему дальнейшую разработку ZFS, благодаря чему мы застряли в прошлом десятилетии с файловыми системами.
P.S.: Снапшоты при помощи систем виртуализации для файлового хранилища — это как-то странно. У решений поверх стандартных файловых систем они дадут значительно больший оверхед, у VMWare они интегрированы с файловой системой (=тот же подход, что у wafl/zfs)
Пин-код от карты, отжатой мускуклистыми молодцами, можно попытаться не сказать, а вот не показать лицо банкомату — несколько сложнее. Или Сбербанк будет распознавать эмоции?
Удаление (да и вообще модификация) записей через LIMIT в случае statement-based репликации — не самая хорошая идея. Лучше уж использовать диапазон значений первичного ключа (id >= 5000 AND id < 10000).
Также, в отдельных случаях может быстрее оказаться выбрать оставляемые записи в новую таблицу, на старую сделать truncate, и залить данные обратно. Или просто удалить таблицу, если в нее не ведется запись, а новую переименовать
Ну и конечно, можно таблицы партицировать, в том числе и по времени, и удалять ненужные партиции целиком.
Такие опции будут выдавать Warning при подключении, если не указать -o LogLevel=ERROR. Ну и конечно, их можно не указывать каждый раз, а засунуть в конфиг — ~/.ssh/config:
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
LogLevel=ERROR
Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные. А вот проброшенный SSH-агент (ForwardAgent=yes) может представлять интерес для такой атаки
судя по статье, это были реальные платежные операции из копии продакшен-базы, которые в результате «обезличивания», (а вернее чистки части данных с продакшена), потеряли связь с заказами. А поскольку транзакции и реляционная целостность в современном мире считается устаревшим подходом, для приведения базы в порядок был специальный сервис, отменяющий платежные операции, не привязанные к заказам. Интересно, почему на продакшене нельзя было делать этого вручную, или может даже исправить причину появления таких операций?
На мой взгляд, идея не самя удачная — WAL логи не слишком хорошо подходят для извлечения из них запросов, это лог изменения данных на диске. Из самих WAL файлов (без наличия реплики с реплицированной базой) эту информацию извлечь невозможно.
Если серверов — десятки, то лучше мониторить количество логических дисков с статусом отличным от optimal, и на него повесить триггер. Читать текст SMART в заббиксе — странная идея, если есть реальная необходимость в ранних предупреждениях, то надо мониторить конкретные параметры. Но вообще сбой одного диска — вполне нормальная ситуация для RAIDа, зачем слушать подземный стук, когда проще заменить диск после выхода из строя?
Алиэкспресс — это маркетплейс, почти как яндекс маркет ;) Продавцы получают оплату, а отправляют они посылку или нет — установить невозможно. Али при поступлении жалоб на недоставку деньги с продавца снимает, и если таких жалоб очень много — блокирует. Если продавец не отправляет посылки в рамках средней статистики его поймать невозможно.
Этот статус (неудачная попытка вручения) означает, что выписано почтовое извещение. А то статус, что посылка прибыла в отделение ничего не означает — она там может месяц неоприходованной валяться.
Речь про регистрируемые отправления, то есть с треком (идентификатором). У них, помимо того, может быть объявленная ценность (страховка), и в случае утери, повреждения, кражи с изменением веса отправителю может быть выдано денежное возмещение за счет почты. Терять или выдавать такие посылки кому ни попадя почте выйдет дороже. Без паспорта их выдать наверное могут, но вот без знания трекингового идентификатора — маловероятно. Потому везде и пишут — не публикуйте номера треков до получения посылок.
Нерегистрируемые могут засовывать и в ящик (мне лично такой вариант удобнее), за них никто не отвечает, страховать их тоже не будут.
Для обладателей VLC (и не только) подойдет такой вариант — делается m3u8 плейлист с HLS потоком, и урлом для запроса ключа расшифровки. Отдается этот m3u8 как application/octet-stream, юзер скачивает и запускает его. Никаких 10k$ не нужно
Отметка о вручении в треке ставится после получения посылки. При неполучении в течении срока хранения (3 недели вроде), посылку отправляют обратно с пометкой в треке о невручении. При этом, при наличии трекингового номера можно распечатать с сайта pochta.ru квитанцию, и идти с ней требовать либо посылку, либо официальную бумагу о «не нашли». Также на этой распечатанной квитанции написано что делать, если посылку по ней не отдают. Практика показывает, что простое требование бумаги о ненайденной посылке творит чудеса — буквально за пару минут все находят
не нужен никакой двойной объем памяти, CoW существует с незапамятных времен. Форк процесса редиса наследует его память в состоянии «снапшота», и просто записывает ее на диск, упаковывая в более компактный формат хранения
Вероятно, имелось ввиду что девелоперская база находится в DMZ и снаружи недоступна. Непущать разработчиков продакшен базу — в целом здравая идея. Пусть разрабатывают набор начальных данных для заливки на тестовую базу. И на все вопросы отвечают — а у нас все работает ;)
Загрузка полного дампа на больших базах — это последнее средство, когда все плохо. У меня только дамп базы делается несколько дней, загрузка его — раза в полтора-два дольше. А накатывание архивлогов ведется в один поток, и при большом потоке изменений в базе накатить логи за 4 дня займет едва ли не сутки.
В этом случае снапшоты — наше все. Они в случае btrfs практически бесплатные — то есть расходуют только занимаемое место, по объему примерно как сжатые gzip'ом архивлоги. Хранить их можно, пока свободное место позволяет (процентов до 20).
Снапшоты в btrfs — записываемые (вернее, доступен для записи каталог, куда снапшот монтируется). Нет необходимости переводить основную реплику в мастер, можно поднять еще один постгрес (лучше еще один контейнер) на снапшоте и его перевести в мастер. В этом случае не придется нагонять репликацию — у вас всегда будет актуальная реплика, с нее можно снимать дампы (хотя в этом есть нюансы).
В таком сценарии делать снапшоты базы без ее остановки весьма удобно — у вас всегда есть некоторое количество снапшотов, для отката базы или для поднятия тонких копий в качестве девелоперской базы
Нет особого смысла хранить архивлоги за большой период. Если только вам не нужно откатиться на заданную минуту в прошлом, тогда пригодятся и снапшоты и архивлоги. Для случаев отставания реплики достаточно периода в несколько дней. Само отставание (в секундах) мониторить можно так select extract(epoch from now() - pg_last_xact_replay_timestamp())::integer
Останавливать базу для создания снапшота необязательно, достаточно выполнить два запроса
В крупных компаниях управлять Delphix все равно будет админ (как минимум настраивать полномочия для представителей каждой из 4х групп разработчиков), да и обычно разбираться в интерфейсе никому не охота, а отправить письмо «Вась, откати базу db4 на вчера» куда проще. Но ок, запишем это как преимущество.
Никакой экономии пространства у Delphix по сравнению с клонами нет.
Снапшоты — почти эквивалент откатыванию на любой период времени, с поправкой на частоту их создания. Точность до секунды для дев-БД врядли нужна.
Вебинтерфейс для управления снапшотами есть и у СХД
Так что скажем спасибо IBM за многомилионные мейнфреймы, благодаря которым у каждого есть дешевые компьютеры, скажем спасибо NetApp, что их разработки, окупившись в энтерпрайзе, пошли «в народ», и скажем «спасибо» Ораклу, похоронившему дальнейшую разработку ZFS, благодаря чему мы застряли в прошлом десятилетии с файловыми системами.
P.S.: Снапшоты при помощи систем виртуализации для файлового хранилища — это как-то странно. У решений поверх стандартных файловых систем они дадут значительно больший оверхед, у VMWare они интегрированы с файловой системой (=тот же подход, что у wafl/zfs)
Также, в отдельных случаях может быстрее оказаться выбрать оставляемые записи в новую таблицу, на старую сделать truncate, и залить данные обратно. Или просто удалить таблицу, если в нее не ведется запись, а новую переименовать
Ну и конечно, можно таблицы партицировать, в том числе и по времени, и удалять ненужные партиции целиком.
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
LogLevel=ERROR
Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные. А вот проброшенный SSH-агент (ForwardAgent=yes) может представлять интерес для такой атаки
Нерегистрируемые могут засовывать и в ящик (мне лично такой вариант удобнее), за них никто не отвечает, страховать их тоже не будут.
В этом случае снапшоты — наше все. Они в случае btrfs практически бесплатные — то есть расходуют только занимаемое место, по объему примерно как сжатые gzip'ом архивлоги. Хранить их можно, пока свободное место позволяет (процентов до 20).
Снапшоты в btrfs — записываемые (вернее, доступен для записи каталог, куда снапшот монтируется). Нет необходимости переводить основную реплику в мастер, можно поднять еще один постгрес (лучше еще один контейнер) на снапшоте и его перевести в мастер. В этом случае не придется нагонять репликацию — у вас всегда будет актуальная реплика, с нее можно снимать дампы (хотя в этом есть нюансы).
В таком сценарии делать снапшоты базы без ее остановки весьма удобно — у вас всегда есть некоторое количество снапшотов, для отката базы или для поднятия тонких копий в качестве девелоперской базы
select extract(epoch from now() - pg_last_xact_replay_timestamp())::integer
Останавливать базу для создания снапшота необязательно, достаточно выполнить два запроса
и после создания снапшота
Никакой экономии пространства у Delphix по сравнению с клонами нет.
Снапшоты — почти эквивалент откатыванию на любой период времени, с поправкой на частоту их создания. Точность до секунды для дев-БД врядли нужна.
Вебинтерфейс для управления снапшотами есть и у СХД