КУК без потерь
Катастрофоустойчивый кластер (КУК) подразумевает небольшую потерю данных при катастрофе основного Дата-центра (ДЦ) и переключении на резервный. Это обусловлено асинхронной репликацией между основным и резервным ДЦ. Но есть решение, которое позволит исправить эту ситуацию - обеспечить нулевую потерю данных при катастрофе основного ДЦ. Об этом решении и пойдет речь в моем докладе.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
45 мин
Анатолий Анфиногенов АО "ВНИИЖТ" Зам. директора научного центра - начальник отдела разработки ПОЖизнь после импортозамещения: некоторые особености настройки БД и хранимых процедур
Многие литературные произведения заканчиваются свадьбой, а про дальнейшую жизнь героев читателю скупо сообщают, что они жили долго и счастливо. В 2019 распределенное серверное приложение, работающего 24/7 на полигоне 16 железных дорог от Калининграда до Хабаровска плюс несколько БД центрального уровня, было перенесено с Oracle 11g SE на ванильный PostgreSQL 11.9. Но наша история не закончилась на успешном импортозамещении - жизнь продолжалась и порой преподносила сюрпризы. Мы столкнулись с некоторым количеством эксплуатационных проблем, часть из которых удалось решить за счет реорганизации данных, часть - за счет изменения хранимых процедур, а еще часть - за счет изменения парамеров PostgreSQL. Решение наших проблем было бы невозможным без встроенной в приложение системы логирования и профилирования. Доклад посвящен примерам успешного диагностирования и решения проблем с производительностью приложения для БД PostgreSQL, все взаимодействие с которым осуществляется только через слой хранимых процедур.
-
45 мин
Виктор Бушмин Росгосстрах Директор направленияЭволюция системы от MVP до HighLoad (опыт с ОСАГО)
В июне 2020 года АльфаСтрахование, как и другие страховые компании, была обязана использовать АИС РСА 2.0 для обеспечения работы ОСАГО в соответствии с законодательством. Компания занимает ведущие позиции на рынке ОСАГО, поэтому системы АИС ОСАГО, которые хранят информацию по обращениям от бизнес-систем до РСА и обратно, начали испытывать неожиданную нагрузку, БД стала деградировать, потреблять огромные для ее размера ресурсы. Деградация внезапно наступала и внезапно заканчивалась, причины были неясны. Творческий коллектив инженеров и экспертиза Postgres Pro решили проблему. Виновником оказался MyBatis (ORM) в Java-сервисах. История о том, что надо внимательно изучать документацию и проектировать высоконагруженные системы.
-
45 мин
.JPG.180x180.jpg "Павел Толмачев")
Павел Толмачев Postgres Professional Специалист образовательного отделаКоллапс в планах запросов. Достигаем и управляем
Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.
-
22 мин
Иван Чувашов ООО Calltouch DBAПовреждение данных PostgreSQL на жестком диске. Что делать и как исправить?
Любая СУБД хранит свои данные на жестком диске, следовательно, может произойти ситуация, когда данные на диске повредились. Это может быть сбой контроллера, логическое или физическое повреждение данных, есть и масса других причин. Хорошо, когда в таких ситуациях повреждается файл индекса, команда пересоздания индекса позволяет восстановить консистентность в СУБД. Гораздо хуже дело обстоит, когда поврежден файл таблицы или системного раздела, восстановить поврежденные данные тогда невозможно. Приходиться прибегать к разным ухищрениям. Это может быть восстановление из бекапа, копирование данных из поврежденной таблицы или другие способы. В докладе рассмотрим несколько случаев повреждения данных на диске и опишем варианты восстановления данных из поврежденных таблиц.