Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Структуры данных в разделяемой памяти,
про алгоритмы замещения страниц в буфере и блокировки, которые используются на разных уровнях взаимодействия.
А также средства мониторинга памяти, уже существующие и те, которые ещё только в процессе разработки.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Отказоустойчивая обработка 10M OAuth токенов на Tarantool / Владимир Перепели...Ontico
Многие современные высоконагруженные системы построены с использованием очередей. Не является исключением и внутренний сервис обработки OAuth токенов, который создала наша команда. Исключением является то, что и в качестве основного хранилища, и в качестве всех очередей используется один и тот же продукт - Tarantool. Более того, мы поставили себе амбициозную цель по отказоустойчивости - полную доступность сервиса, когда уходят любые два из трёх датацентров, и успешно её достигли.
При решении мы столкнулись с массой интересных инженерных задач и в нашем докладе мы расскажем вам о том, какие технологии и подходы использовались. В частности, рассмотрим более детально такие вещи, как:
- создание deadline очереди и проблемы, с ней связанные;
- создание кольцевой очереди;
- интеграция между собой шардинга, Raft и очередей;
- как мы победили split brain ;)
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico
RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных.
В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Структуры данных в разделяемой памяти,
про алгоритмы замещения страниц в буфере и блокировки, которые используются на разных уровнях взаимодействия.
А также средства мониторинга памяти, уже существующие и те, которые ещё только в процессе разработки.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Отказоустойчивая обработка 10M OAuth токенов на Tarantool / Владимир Перепели...Ontico
Многие современные высоконагруженные системы построены с использованием очередей. Не является исключением и внутренний сервис обработки OAuth токенов, который создала наша команда. Исключением является то, что и в качестве основного хранилища, и в качестве всех очередей используется один и тот же продукт - Tarantool. Более того, мы поставили себе амбициозную цель по отказоустойчивости - полную доступность сервиса, когда уходят любые два из трёх датацентров, и успешно её достигли.
При решении мы столкнулись с массой интересных инженерных задач и в нашем докладе мы расскажем вам о том, какие технологии и подходы использовались. В частности, рассмотрим более детально такие вещи, как:
- создание deadline очереди и проблемы, с ней связанные;
- создание кольцевой очереди;
- интеграция между собой шардинга, Raft и очередей;
- как мы победили split brain ;)
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico
RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных.
В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Технопарк Mail.ru Group, МГТУ им. Н.Э. Баумана. Курс "Базы данных".
Лекция №9 "Безопасность баз данных". Лектор - Павел Щербинин.
Открывается лекция рассказом о резервном копировании (о логических и физических резервных копиях, о выборе данных для копирования). Затем определяется терминология для обсуждения дальнейших вопросов. После этого рассматриваются основы учётных записей: таблицы доступа, привилегии, виды записей. Обсуждаются SQL-injection, список смежных вершин (Adjacency Set), вложенное множество (Nested Set), материализованный путь (Materialized Path) и комбинированный подход.
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9obOz5K695ugYuiOOCBciEi
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных.
OpenSource SQL Databases Enter Millions Queries per Second EraSveta Smirnova
Доклад прочитан на Highload++ 8 ноября 2016 года совместно с Фёдором Сигаевым и Анастасией Распопиной. Подготовка слайдов совместно с Александром Коротковым.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
PgCenter is a tool for monitoring and troubleshooting PostgreSQL. It provides a graphical interface to view key performance metrics and statuses. Some of its main features include displaying server health, load, memory and disk usage, statement performance, replication status and more. It aims to help PostgreSQL administrators quickly check the health of their databases and identify potential problems.
1. A PostgreSQL database outage occurred at GitLab on January 31st due to a combination of factors including an increase in load, replication lag, and the deletion of the database directory.
2. Lessons learned include monitoring replication, using tools like pg_basebackup properly, and having backups and disaster recovery processes in place.
3. Recommended preventative measures include setting sane configuration values, automated testing of backups, assigning an owner for data durability, and improving documentation.
This document provides an overview of troubleshooting streaming replication in PostgreSQL. It begins with introductions to write-ahead logging and replication internals. Common troubleshooting tools are then described, including built-in views and functions as well as third-party tools. Finally, specific troubleshooting cases are discussed such as replication lag, WAL bloat, recovery conflicts, and high CPU recovery usage. Throughout, examples are provided of how to detect and diagnose issues using the various tools.
This presentation discusses optimizing Linux systems for PostgreSQL databases. Linux is a good choice for databases due to its active development, features, stability, and community support. The presentation covers optimizing various system resources like CPU scheduling, memory, storage I/O, and power management to improve database performance. Specific topics include disabling transparent huge pages, tuning block I/O schedulers, and selecting appropriate scaling governors. The overall message is that Linux can be adapted for database workloads through testing and iterative changes.
This document provides an overview of pgCenter, a tool for managing and monitoring PostgreSQL databases. It describes pgCenter's interface which displays system metrics, PostgreSQL statistics and additional information. The interface shows values for items like CPU and memory usage, database connections, autovacuum operations, and query information. PgCenter provides a quick way to view real-time PostgreSQL and server performance metrics.
Nine Circles of Inferno or Explaining the PostgreSQL VacuumAlexey Lesovsky
The document describes the nine circles of the PostgreSQL vacuum process. Circle I discusses the postmaster process, which initializes shared memory and launches the autovacuum launcher and worker processes. Circle II focuses on the autovacuum launcher, which manages worker processes and determines when to initiate vacuuming for different databases. Circle III returns to the postmaster process and how it launches autovacuum workers. Circle IV discusses what occurs within an autovacuum worker process after it is launched, including initializing, signaling the launcher, scanning relations, and updating databases. Circle V delves into processing a single database by an autovacuum worker.
This document discusses streaming replication in PostgreSQL. It covers how streaming replication works, including the write-ahead log and replication processes. It also discusses setting up replication between a primary and standby server, including configuring the servers and verifying replication is working properly. Monitoring replication is discussed along with views and functions for checking replication status. Maintenance tasks like adding or removing standbys and pausing replication are also mentioned.
The document provides configuration instructions and guidelines for setting up streaming replication between a PostgreSQL master and standby server, including setting parameter values for wal_level, max_wal_senders, wal_keep_segments, creating a dedicated replication role, using pg_basebackup to initialize the standby, and various recovery target options to control the standby's behavior. It also discusses synchronous replication using replication slots and monitoring the replication process on both the master and standby servers.
This document discusses PostgreSQL statistics and how to use them effectively. It provides an overview of various PostgreSQL statistics sources like views, functions and third-party tools. It then demonstrates how to analyze specific statistics like those for databases, tables, indexes, replication and query activity to identify anomalies, optimize performance and troubleshoot issues.
This document discusses using PostgreSQL statistics to optimize performance. It describes various statistics sources like pg_stat_database, pg_stat_bgwriter, and pg_stat_replication that provide information on operations, caching, and replication lag. It also provides examples of using these sources to identify issues like long transactions, temporary file growth, and replication delays.
This document provides an overview of pgCenter, an open source tool for monitoring and managing PostgreSQL databases. It summarizes pgCenter's main features, which include displaying statistics on databases, tables, indexes and functions; monitoring long running queries and statements; managing connections to multiple PostgreSQL instances; and performing administrative tasks like viewing logs, editing configuration files, and canceling queries. Use cases and examples of how pgCenter can help optimize PostgreSQL performance are also provided.
Slides from Secon'2015 - Software Developers Conference. Penza, Russia.
The database is an essential element of any project. The database must be stable and provide good performance. If you plan to use PostgreSQL in your project, you will run into question the choice of operating system. Linux is one of the most popular operating system today. The combination of flexibility and stability makes Linux a good candidate as a platform for PostgreSQL. However, the default settings are suitable for a wide range of workloads. In this report, I will talk about what settings should pay attention and how they affect the performance of PostgreSQL. Which of these settings are more important, and what - no. How do the PostgreSQL more predictable and stable under normal circumstances or in cases of increasing load.
2. dataegret.com
Введение
• Что такое репликация и зачем.
• Какая бывает репликация.
• Как устроена потоковая репликация в PostgreSQL.
Настройка
• Настройка потоковой репликации.
• Проверка результата.
• Особенности эксплуатации.
02
01
6. Логическая репликация01
dataegret.com
Плюсы:
● Работает между разными версиями и архитектурами.
● Позволяет реплицировать отдельные наборы таблиц.
Минусы:
● Сложность в реализации синхронной репликации.
● Утилизация CPU (триггеры, преобразование текста, ...).
Примеры:
● Slony, Londiste (Skytools), Bucardo, Pglogical.
7. Физическая репликация01
dataegret.com
Плюсы:
● Небольшие накладные расходы на использование ресурсов.
● Легкость установки и обслуживания.
Минусы:
● Запасные узлы доступны только для чтения.
● Не работает между разными версиями и архитектурами.
● Не умеет реплицировать наборы таблиц.
8. REDO журнал01
dataegret.com
Необходимость подтверждать все изменения (Durability в ACID).
Все (почти) изменения записываются в REDO журнал.
REDO журнал это история «последних» изменений.
REDO журнал используется:
● При аварийном восстановлении;
● При резервном копировании;
● При репликации.
9. REDO журнал в PostgreSQL01
dataegret.com
В PostgreSQL, REDO журнал называется Write Ahead Log (WAL).
WAL гарантирует что информация об изменениях будет
зафиксирована ДО реальных изменений.
Как это работает:
● LSN (log sequence number) – положение записи внутри WAL;
● Страницы маркируются LSN;
● Перед записью страницы на диск, проверяем что LSN уже
записан в журнал.
11. Startup процесс01
dataegret.com
Главный компонент который запускает СУБД.
Запускается восстановление по WAL журналу.
Чтение конфигурации и определение источника WAL.
REDO цикл:
● Чтение WAL из pg_xlog/ или WAL архива;
● Установка соединения с upstream.
12. WAL Receiver процесс01
dataegret.com
WAL receiver:
● Определение с какого места начать прием WAL;
● Подключение к мастеру и отправка LSN отметки;
● Принимает WAL и записывает на диск;
● Обновляет особую переменную в shared memory;
● Отправляет статистику на мастер.
Startup процесс использует особую переменную чтобы
воспроизвести WAL до этого места.
13. WAL Sender процесс01
dataegret.com
Для каждого клиента, создается отдельный backend-процесс.
WAL sender это тоже backend.
WAL sender запускает репликацию.
Отправляет WAL журнал клиенту.
Или спит если нет новых журналов.
14. Упрощенный порядок работы01
dataegret.com
Мастер Реплика
Запуск WAL sender и получение позиции
Проверка наличия журнала
Отправка журнала
Обновление статистики
Проверка источника XLOG
Запуск WAL receiver
Вычисление стартовой позиции
Подключение к мастеру, отправка
позиции
Запись журнала на диск
Обновление «отметки»
Отправка статистики
Воспроизведение журнала
Начальная фаза
Цикл репликации
20. Настройка мастера02
dataegret.com
Отдельный пользователь для репликации (psql или createuser).
● CREATE ROLE replica WITH LOGIN REPLICATION PASSWORD '123';
Правка postgresql.conf.
Правка pg_hba.conf.
Создание слота репликации (необязательно).
31. Проверка результата02
dataegret.com
Наличие процессов WAL sender и WAL receiver.
master $ ps aux |grep -i wal
postgres: wal sender process postgres [10.1.0.99] streaming 4/EA000060
standby $ ps aux |grep -i wal
postgres: wal receiver process streaming 4/EA000060
32. Проверка результата02
dataegret.com
Проверка системного журнала.
LOG: database system was interrupted; last known up at 2017-02-10 12:28:54
LOG: entering standby mode
LOG: redo starts at 4/E9000028
LOG: consistent recovery state reached at 4/E9000130
LOG: database system is ready to accept read only connections
LOG: started streaming WAL from primary at 4/EA000000 on timeline 1
39. Особенности эксплуатации02
dataegret.com
DDL и autovacuum может аффектить запросы на реплике:
● Конфликты репликации.
● pg_stat_database_conflicts.
● hot_standby_feedback = on.
● max_standby_streaming_delay = ...