PostgreSQL и резервное копирование
Резервное копирование это то, без чего не должна обходится эксплуатация PostgreSQL, поскольку позволяет восстановить систему в случае сбоя.
Мы обсудим, почему резервное копирование необходимо при грамотной эксплуатации PostgreSQL (хотя это и кажется очевидным), а также рассмотрим различные опции, доступные для формирования хорошей стратегии резервирования. На этой основе, поговорим о будущем резервного копирования, особенно в свете различных инструментов резервирания, набирающих популярность у пользователей с большими объемами данных.
Материалы к докладу
Слайды
Видео
Другие доклады
-
Алексей Лесовский PostgreSQL Consulting LLC Администратор баз данных
Потоковая репликация на практике.
Потоковая репликация это одна из тех прорывных технологий которая вывела PostgreSQL на совершенно новый уровень. Сочетая в себе легкость настройки, высокую производительность и почти неограниченную масштабируемость потоковая репликация является эффективным инструментом, а ее наличие становится неотъемлемым компонентом любого постгресового "сетапа". Более того, в процессе дальнейшего развития PostgreSQL, потоковая репликация продолжает развиваться и обзаводиться новыми функциями (каскадные конфигурации, слоты репликации) вплоть до того, что на данном этапе своего развития, потоковая репликация позволяет выстраивать bi-directional replication конфигурации.
Из доклада вы узнаете о том, как устроена потоковая репликация снаружи и внутри, и о практических аспектах эксплуатации потоковой репликации включая такие вещи как настройка, сопровождение, мониторинг, поиск и устранение проблем.
Участникам мастер-класса следует скачать себе образ виртуальной машины для KVM, Virtual box или VMWare, распаковать его (gzip2) и запустить виртуальную машину.
Если у Вас нет ни одной из перечисленных программ для виртуализации, то нужно запустить виртуальную машину с CentOS 7 и установленным postgresql из оф.репозитория yum.postgresql.org.
Ссылка на образы для скачивания: https://goo.gl/Yy4UzH
-
Kevin Grittner EnterpriseDB
Всё об изоляции транзакций в PostgreSQL для разработчиков приложений
Когда множество пользователей, процессов или потоков выполнения одновременно модифицируют их общие данные, это может вызывать проблемы, если каким-то образом не урегулировать условия гонки. Эти проблемы особенно остро проявляются в базах данных, реализующих семантику ACID. Набор изменений, объединённых в транзакцию базы данных, должен проявляться атомарно, и для параллельных транзакций, и для процесса восстановления после сбоя. Каждая транзакция должна переводить базу данных из одного согласованного состояния (с точки зрения бизнес-правил) в другое. Для эффективной разработки необходимо иметь возможность запрограммировать каждую транзакцию независимо от других транзакций, которые по стечению обстоятельств могут выполняться в то же самое время. В случае сбоя все изменения, внесённые транзакциями, об успешном завершении которых были уведомлены приложения, а также все изменения, ставшие видимыми для других транзакций, должны оставаться в базе после восстановления. За многие годы были выработаны различные стратегии обеспечения этих гарантий, а иногда гарантии корректировались тем или иным способом. В данном докладе будет рассказано, каким образом обеспечиваются эти гарантии или их компромиссные варианты, с упором на методику сериализуемой изоляции снимков (SSI, Serializable Snapshot Isolation), применяемую в PostgreSQL (и ни в какой другой производственной СУБД на данный момент). Хотя SSI уже работает быстрее и с большей степенью параллельности, чем любая другая методика управления условиями гонки с наиболее типичной нагрузкой, есть много путей для дальнейшего увеличения производительности, некоторые из которых требуют помощи эксперта по различным методам доступа индексов; эти вопросы и будут обсуждены в данном докладе. Кроме того, на докладе будут представлены некоторые общие идеи о том, как можно использовать методики SSI с XTM в распределённой системе. В конце мы оставили время для группового обсуждения оптимизации и возможных применений в распределённой среде.
-
Владимир Ситников Pgjdbc, JMeter committer Инженер по производительности
PostgreSQL и JDBC: выжимаем все соки
Все говорят, что для максимальной производительности работы из Java с базой данных нужно использовать PreparedStatements и Batch DML. Практика показывает, что нельзя слепо идти на поводу у прописных истин. Нужно понимать особенности конкретной базы и характера передаваемых данных. В докладе мы рассмотрим то, как эффективное использование протокола PostgreSQL позволяет добиться высокой производительности при выборке и сохранении данных. На примерах увидим как простые изменения в коде приложения и JDBC драйвера на порядок ускоряют запросы. Мы увидим как задействовать механизм server prepared statements из клиенсткого кода и узнаем его узкие места. Обсудим средства эффективной передачи данных в базу. Многие обсуждаемые доработки недавно вошли в состав официального JDBC драйвера. Доклад будет полезен не только Java программистам, т.к. многие подводные грабли вытекают из самого протокола общения PostgreSQL с внешним миром.
-
Дмитрий Бойков АО БАРС Груп Руководитель отдела разработкиМарат Фаттахов АО "БАРС Груп" Технический директор
Портирование облачного решения с Oracle на PostgreSQL: опыт компании "БАРС Груп"
Изначально компания «БАРС Груп» была ориентирована на задействование в своих проектах СУБД Oracle, но появление PostgreSQL игнорировать не могла. На конференции мы расскажем, как пришли к использованию PostgreSQL и поделимся опытом перевода на эту СУБД большой медицинской информационной системы.
- Опыт использования СУБД PostgreSQL и Oracle в проектах компании. Предпосылки и мотивация использования СУБД PostgreSQL.
Ход и результаты эксперимента миграции медицинской информационной системы:
- разработка утилиты конвертации кода PL/SQL в PgSQL;
- проблемы переноса сложных пакетов;
- патчи к PostgreSQL как варианты решения этих проблем.