#репликация_базы_данных — Public Fediverse posts

[Перевод] Хотели ускорить Postgres, а построили платформу репликации данных

Команда Go for Devs подготовила перевод статьи инженеров Datadog о том, как из разрозненных пайплайнов вырастить надёжную мультитенантную платформу репликации данных. В материале — практический опыт масштабирования PostgreSQL, переход к асинхронной репликации, автоматизация через Temporal, работа с CDC и Kafka, а также реальные компромиссы между согласованностью, надёжностью и задержками.

https://habr.com/ru/articles/985236/

#репликация_базы_данных #асинхронное_программирование #cdc #postgres #kafka #temporal

[Перевод] Хотели ускорить Postgres, а построили платформу репликации данных

Команда Go for Devs подготовила перевод статьи инженеров Datadog о том, как из разрозненных пайплайнов вырастить надёжную мультитенантную платформу репликации данных. В материале — практический опыт масштабирования PostgreSQL, переход к асинхронной репликации, автоматизация через Temporal, работа с CDC и Kafka, а также реальные компромиссы между согласованностью, надёжностью и задержками.

https://habr.com/ru/articles/985236/

#репликация_базы_данных #асинхронное_программирование #cdc #postgres #kafka #temporal

[Перевод] Хотели ускорить Postgres, а построили платформу репликации данных

Команда Go for Devs подготовила перевод статьи инженеров Datadog о том, как из разрозненных пайплайнов вырастить надёжную мультитенантную платформу репликации данных. В материале — практический опыт масштабирования PostgreSQL, переход к асинхронной репликации, автоматизация через Temporal, работа с CDC и Kafka, а также реальные компромиссы между согласованностью, надёжностью и задержками.

https://habr.com/ru/articles/985236/

#репликация_базы_данных #асинхронное_программирование #cdc #postgres #kafka #temporal

[Перевод] Хотели ускорить Postgres, а построили платформу репликации данных

Команда Go for Devs подготовила перевод статьи инженеров Datadog о том, как из разрозненных пайплайнов вырастить надёжную мультитенантную платформу репликации данных. В материале — практический опыт масштабирования PostgreSQL, переход к асинхронной репликации, автоматизация через Temporal, работа с CDC и Kafka, а также реальные компромиссы между согласованностью, надёжностью и задержками.

https://habr.com/ru/articles/985236/

#репликация_базы_данных #асинхронное_программирование #cdc #postgres #kafka #temporal

[Перевод] Путь к масштабированию PostgreSQL: от теории к практике

"Postgres масштабируется" - нет других двух слов, которые вызывали бы больше споров. По крайней мере, в кругах, где я общаюсь, в подвале компании, где инфраструктурные эльфы заставляют Rails-приложение работать. Многие верят, вопреки всему и маркетинговым кампаниям Big NoSQL, что знакомая технология лучше, чем новый неизвестный инструмент, о котором только что рассказали на совещании руководства. Честно говоря, я понимаю их позицию. Заставить Postgres писать больше данных может быть сложно. Вам нужно больше оборудования. В большинстве случаев его можно получить, просто нажав кнопку "Обновить". Но когда вы дошли до экземпляра r5.24xlarge с 5 репликами такого же размера, и ваши процессы vacuum всё ещё отстают от графика, ситуация становится довольно пугающей. Именно здесь начинается испытание для настоящего инженера. На пределе возможностей. Я говорю не о WebAssembly . Я говорю об инженерном духе, который смотрит на проблему под давлением руководства и вместо того, чтобы бежать к ближайшей команде продаж с большими обещаниями (но малым количеством фактов о вашем конкретном случае), решает её, используя базовые принципы. А базовый принцип говорит нам, что нам нужно. У Postgres закончилась пропускная способность для записи. Либо из-за блокировок при работе с WAL , либо что-то застопорило vacuum. Вероятно, это та неактивная транзакция, которая открыта уже 45 секунд, пока приложение делает запрос к Stripe, но это не наша забота. Мы - инфраструктурная команда, и наша задача - заставить базу данных работать.

https://habr.com/ru/articles/891122/

#postgresql #шардинг #масштабирование_postgresql #репликация_базы_данных #отказоустойчивость #высокие_нагрузки #базы_данных #devops #оптимизация #инфраструктура

Бэкап, бэкап и еще раз бэкап

Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости. Почему вроде бы правильно настроенное архивирование базы данных не всегда помогает спасти систему в случае инцидентов? Этим вопросом я, наверное, многих даже задел за живое. Одних тем, что сама постановка вопроса им кажется абсурдной – у этой группы админов все настроено идеально, работает как часы и они готовы к любым катаклизмам. А кого-то тем, что напоминаю о тех самых инцидентах, когда возвращаться в тот день, даже мысленно, совсем не хочется. В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости. И если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря. Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.

https://habr.com/ru/companies/softpoint/articles/795305/

#DB_Replication #dbreplication #репликация_базы_данных #отказоустойчивость #резервирование #бэкап #шифровальщик #цод #sql #восстановление_баз_данных

Сказ о том, как РП репликацию на Марии из зеркал состряпал…

Нежданно ни гадано, затеяли значит высшие "итишные" силы включить новые заморские очереди Кафка в уже выполненный на 4/3 проект и слава богу, что только для внешних взаимодействий и передачи всякой информации туды-сюды. Главный архитектор дал благословение и понеслось, да не туда, так как нести то некому это невиданное заморское чудо. Что делать, в обозримые сроки не впихнуть и перед боярами чин и обязательства не сдержать. Посидел РП, погоревал, да сдул пыль со знаний древних и ранее опробованных и тут понеслось.

https://habr.com/ru/articles/809539/

#SQL #руководитель_проектов #mariadb #репликация #репликация_базы_данных

Бэкап, бэкап и еще раз бэкап

Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости. Почему вроде бы правильно настроенное архивирование базы данных не всегда помогает спасти систему в случае инцидентов? Этим вопросом я, наверное, многих даже задел за живое. Одних тем, что сама постановка вопроса им кажется абсурдной – у этой группы админов все настроено идеально, работает как часы и они готовы к любым катаклизмам. А кого-то тем, что напоминаю о тех самых инцидентах, когда возвращаться в тот день, даже мысленно, совсем не хочется. В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости. И если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря. Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.

https://habr.com/ru/companies/softpoint/articles/795305/

#DB_Replication #dbreplication #репликация_базы_данных #отказоустойчивость #резервирование #бэкап #шифровальщик #цод #sql #восстановление_баз_данных