TechCave

Описание сайта

Основная информация

PostgreSQL — свободная объектно-реляционная система управления базами данных (СУБД).

Существует в реализациях для множества UNIX-подобных платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows.

Рейтинг: 0
Создана 2 года назад
Владелец root

Стена группы

Загрузка...
2 года назад
#

Postgres Pro


Postgres Pro — Российская СУБД, разработанная компанией Postgres Professional на основе свободно-распространяемой СУБД PostgreSQL с поддержкой 1С.

Ссылка на github.
2 года назад
#

Что же нового в PostgreSQL 9 6 — Николай Самохвалов


2 года назад
#

Построение кластера на базе Postgres-XL


Проблемы построения высоконагруженных систем включает в себя грамотный архитектурный дизайн приложения, обеспечение взаимодействия аппаратных компонентов, а также проектирование базы данных. Однако оптимизация БД включает в себя много нюансов. Первый шаг на данном пути – оптимизация запросов. Второй – добавление аппаратных мощностей. Третий – вертикальное масштабирование. Но когда данных мер не хватает, единственный возможный вариант оптимизации – горизонтальное масштабирование. В данной работе рассматривается возможности горизонтального масштабирования на основе открытой СУБД PostgreSQL и ее дочернего проекта Postgres-XL.

2 года назад
#

Варианты построения отказоустойчивых систем на основе PostgreSQL


Михаил Кулагин, Postgres Professional

1. Подходы к построению отказоустойчивых систем на примере OpenSource СУБД MySQL и PostgreSQL
1.1. Логическая и физическая репликация
1.2. Подходы по построению и проблемы мультимастер систем
1.3. Сильные и слабые стороны каждого подхода, точки возможной потери данных

2. Штатные возможности отказоустойчивости PostgreSQL
2.1. Синхронная и асинхронная потоковая репликация
2.2. Особенности конфигурирования и точки мониторинга

3. Автоматизация управления отказоустойчивым кластером на примере Pacemaker/Corosync
4. Варианты построения логической репликации в PostgreSQL
5. Ближайшее будущее Postgres: текущие разработки

2 года назад
#

Еще пара слов о потоковой репликации в postgres…


PostgreSQL
Асинхронная потоковая репликация — полезная штука. Для нее нынче есть много различных утилит, можно выстроить большую, мощную и верную систему.

Но предположим, что у Вас небольшая задача, пара серверов и встроенная postgres-репликация. О ее настройке материалов достаточно, и о действиях в случае отказа мастера тоже можно найти.

А вот с вопросом восстановления мастера оказалась беда, поэтому делюсь с Вами собранным по кусочкам с просторов интернета руководством к действию, опробованным и протестеным мною на связках серверов Debian GNU/Linux и FreeBSD 8.2 с PostgreSQL 9.1

Для начала мы имеем:

Serv1 — Мастер
Serv2 — Слейв

Падение Мастера

Предположим, что БД на Serv1 (мастере) обвалилась, погибла и восставать сама никак не будет. При этом Serv2 стабильно работает в режиме слейва.

Тогда на Serv2 в postgresql.conf надо раскомментировать

wal_level = hot_standby
max_wal_senders = 2
wal_keep_segments = 64
archive_mode = on
archive_command = 'cp %p $LOG_DIR/archive/%f Serv1'

Источник
2 года назад
#

Потоковая репликация в PostgreSQL и пример фейловера


Вот многие жалуются, что PostgreSQL сложно масштабировать и нужно быть в нем очень большим специалистом, чтобы настроить обычную master-slave репликацию. По-моему, это все чушь. Не так давно мне потребовалась всего лишь пара часов вдумчивого чтения документации, чтобы во всем разобраться. В этой заметке я постараюсь показать, что с репликацией в PostgreSQL все очень просто. Заодно мы также разберемся, чем потоковая репликация отличается от логической, что такое синхронная и асинхронная репликация, а также как сделать фейловер в случае падения мастера.

Перекрестная ссылка: Вас также может заинтересовать заметка Начало работы с PostgreSQL. В частности, в ней рассказывается, для чего нужны файлы pg_hba.conf и postgresql.conf, как пользоваться утилитой psql, а также как производится резервное копирование и восстановление PostgreSQL. Далее предполагается, что все это вы уже знаете.

Коротко о главном

Когда вы изменяете данные в базе, все изменения пишутся во Write-Ahead Log, или WAL. После записи в WAL СУБД делает системный вызов fsync, благодаря чему данные попадают сразу на диск, а не висят в где-то в кэше файловой системы. Таким образом, если взять и обесточить сервер, при следующей загрузке СУБД прочитает последние записи из WAL и применит к базе данных соответствующие изменения.

Потоковая репликация (streaming replication) в сущности является передачей записей из WAL от мастера к репликам. Писать при этом можно только в мастер, но читать можно как с мастера, так и с реплик. Если с реплики разрешено читать, она называется hot standby, иначе — warm standby. Поскольку во многих приложениях 90% запросов являются запросами на чтение, репликация позволяет масштабировать базу данных горизонтально. Потоковая репликация бывает двух видов — синхронная и асинхронная.

Асинхронная репликация используется в PostgreSQL по умолчанию. При этом методе запрос тут же выполняется на мастере, а соответствующие данные из WAL доезжают до реплик отдельно, в фоне. Недостаток асинхронной репликации заключается в том, что при внезапном падении мастера (например, из-за сгоревшего диска) часть данных будет потеряна, так как они не успели доехать до реплик.

При использовании синхронной репликации данные сначала записываются в WAL как минимум одной реплики, после чего транзакция выполняется уже на мастере. Запросы на запись выполняются медленнее в результате возникающих сетевых задержек (которые, однако, внутри одного ДЦ обычно меньше типичного времени планирования запроса). Кроме того, чтобы запросы на запись не встали колом в результате падения одной из реплик, при использовании синхронной репликации рекомендуется использовать по крайней мере две реплики. Зато потерять данные становится намного сложнее.

Источник
2 года назад
#

Репликация PostgreSQL [GeekBrains]


PostgreSQL очень распространённая реляционная база данных, которую часто используют в проектах с высокими нагрузками и большими объёмами данных. В таких условиях одним из ключевых факторов является «отказоустойчивость» системы. Вариантом решения данной проблемы является репликация базы данных, о чём мы и поговорим на этом вебинаре. А именно:

— репликация, кластеризация и масштабирование PostgreSQL;
— виды репликации;
— необходимые параметры в конфигурационных файлах для репликации;
— сторонний софт, для автоматизации и упрощения этого процесса;
— практическая часть с примерами.

2 года назад
#

Эволюция отказоустойчивости в PostgreSQL: фаза репликации


Мы продолжаем публиковать серию переводов Gulcin Yildirim, разработчика компании 2ndQuadrant, об отказоустойчивости PostgreSQL и сегодня предлагаем вашему вниманию второй пост из серии.

Gulcin приедет на PG Day'17 и лично ответит на вопросы участников, а также расскажет более подробно не только о репликации в PG, но и об автоматизации апгрейдов Постгреса в облаке и не только. Готовьте свои вопросы!



PostgreSQL — это потрясающий проект, который развивается с удивительной скоростью. В этой серии статей мы сфокусируемся на эволюции возможностей отказоустойчивости в PostgreSQL на протяжении всех его версий. Это вторая статья серии, в которой мы поговорим о репликации и её значении для отказоустойчивости и надежности Постгреса.

Источник
2 года назад
#

Лекции Технотрека. Проектирование СУБД (осень 2016)

image


Продолжаем публикацию наших образовательных материалов. Этот курс посвящен изучению основ языка SQL с учетом особенностей объектно-реляционной базы данных PostgreSQL. Программа предусматривает комплексный подход к изучению стандартизованного языка SQL на платформе PostgreSQL, включая некоторые минимальные возможности администрирования пользователей, ролей, схем, базовых таблиц и других объектов базы данных. Мы рассмотрим основы работы с базой данных PostgreSQL и некоторые особенности SQL применительно к ней. Более подробно — под катом.


Источник
2 года назад
#

Миллионы запросов в секунду: мирная битва между PostgreSQL и MySQL’s при сегодняшних требованиях к рабочим нагрузкам

Мы уже упоминали, что в этом году тематика конференции PG Day’17 Russia значительно расширилась. Совместно с компанией Percona мы сформировали отдельный поток выступлений по MySQL/NoSQL. Помимо докладов от ведущих специалистов по открытым базам данных и no sql решениям, в рамках конференции состоятся также 2 эксклюзивных мастер-класса от ведущих специалистов Percona — Петра Зайцева и Светы Смирновой.



На мастер-классах будут рассмотрены самые различные темы по базам MySQL: создание и использование тестового сервера, тонкости отладки медленных запросов, особенности систем блокировок, влияние оборудования и конфигурации на производительность, сбор данных с минимальной нагрузкой на сервер.

Сегодня предлагаем вашему вниманию перевод небольшого обзора, в котором Света Смирнова ‒ старший инженер службы технической поддержки Percona и Анастасия Распопина, специалист по маркетингу, сравнивают как PostgreSQL и MySQL справляются с миллионами запросов в секунду.

5-го июля для участников PG Day’17 Светлана более подробно расскажет про архитектуру MySQL сервера и специфику работы с разными его частями, такими как оптимизатор, табличные движки, системы блокировок.

Анастасия: Могут ли базы данных с открытым исходным кодом справиться с миллионом запросов в секунду? Многие защитники открытого исходного кода ответят «да». Однако утверждений недостаточно для обоснованных доказательств. Именно поэтому в этой статье мы делимся результатами тестов от Александра Короткова (CEO of Development, Postgres Professional) и Светы Смирновой (главный инженер по техническому обслуживанию, Percona). Сравнительное исследование производительности PostgreSQL 9.6 и MySQL 5.7 будет особенно полезно для окружений с несколькими базами данных.

Источник
2 года назад
#

PostgreSQL libpq connection pool


Для работы с PostgreSQL на языке С++, есть замечательная библиотека libpq. Библиотека отлично документирована, есть даже полный перевод на русский язык, от компании PostgresPRO.

При написании серверного бекэнда, столкнулся с тем, что в этой библиотеке нет никакого пула коннектов, а работа с БД, предполагалась в довольно интенсивном режиме и одного коннекта было явно мало. Каждый раз устанавливать соединение для отправки полученных данных, было бы просто безумием, т.к. соединение самая долгая операция, решено было написать свой пул коннектов.

Идея в том, что мы при старте программы создаём несколько соединений и храним их в очереди.

Когда приходят данные, мы просто берём свободное соединеие из очереди, а если свободных соединений нет — ждём когда появится, используем его для вставки данных, а затем помещаем соединение обратно. Идея довольна простая, быстро реализуема и самое главное, скорость работы очень высокая.

Создадим в PostgreSQL базу с именем demo, табличкой demo такой

-- Table: public.demo

-- DROP TABLE public.demo;

CREATE TABLE public.demo
(
  id integer NOT NULL DEFAULT nextval('demo_id_seq'::regclass),
  name character varying(256),
  CONSTRAINT demo_pk PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.demo
  OWNER TO postgres;

Пишем класс который будет представлять собой соединение к БД, параметры соединения, будут прописаны прямо в коде для его упрощения, в реальности конечно их надо хранить в конфигурационном файле и при запуске считывать оттуда, чтобы при изменении парметров сервера, не приходилось перекомпилировать программу.

#ifndef PGCONNECTION_H
#define PGCONNECTION_H

#include <memory>
#include <mutex>
#include <libpq-fe.h>

class PGConnection
{
public:
    PGConnection();
    std::shared_ptr<PGconn> connection() const;

private:
    void establish_connection();

    std::string m_dbhost = "localhost";
    int         m_dbport = 5432;
    std::string m_dbname = "demo";
    std::string m_dbuser = "postgres";
    std::string m_dbpass = "postgres";

    std::shared_ptr<PGconn>  m_connection;

};


#endif //PGCONNECTION_H


#include "pgconnection.h"
PGConnection::PGConnection()
{
    m_connection.reset( PQsetdbLogin(m_dbhost.c_str(), std::to_string(m_dbport).c_str(), nullptr, nullptr, m_dbname.c_str(), m_dbuser.c_str(), m_dbpass.c_str()), &PQfinish );

    if (PQstatus( m_connection.get() ) != CONNECTION_OK && PQsetnonblocking(m_connection.get(), 1) != 0 )
    {
       throw std::runtime_error( PQerrorMessage( m_connection.get() ) );
    }

}


std::shared_ptr<PGconn> PGConnection::connection() const
{
    return m_connection;
}

Чтобы предотвратить возможную утечку ресурсов, соединиение мы будем хранить в умном указателе.

Подробнее
3 4

Авторизация

Войти с помощью

Пользователи

GeekBrains

КАРКАМ

Нетология