Доступна (https://www.postgresql.org/about/news/1749/) для тестирования бета-версия СУБД PostgreSQL 10 (https://www.postgresql.org/docs/devel/static/release-10.html). Релиз ожидается в начале осени.
Основные (https://wiki.postgresql.org/wiki/New_in_postgres_10) улучшения (http://rhaas.blogspot.com/2017/04/new-features-coming-in-pos...:- Режим логической репликации (https://blog.2ndquadrant.com/logical-replication-postgresql-... позволяющий выборочно реплицировать только заданные таблицы или использовать репликацию в процессе обновления до новой значительной ветки. Логическая репликация манипулирует логическими изменениями на уровне выполняемых операций, в то время как традиционная репликация работает на очень низком уровне, перенося байтовые изменения в WAL-журнале;
- Добавлены встроенные возможности партицирования таблиц по диапазонам значений и спискам - разбивка теперь задаётся (https://www.postgresql.org/docs/devel/static/ddl-partitionin... через выражения "PARTITION BY" и "PARTITION OF" в директиве "CREATE TABLE". Например:
CREATE TABLE padre (
id serial not null,
nombre text not null,
fch_creado timestamptz not null
)
PARTITION BY RANGE ( id );CREATE TABLE hijo_0
partition of padre (id, primary key (id), unique (nombre))
for values from (unbounded) to (9);CREATE TABLE hijo_1
partition of padre (id, primary key (id), unique (nombre))
for values from (10) to (unbounded);- Обеспечено распараллеливание с задействованием нескольких ядер CPU таких операций, как сканирование индексов и битовых карт, выполнение запросов со слиянием таблиц (JOIN);
- Возможность подтверждения коммитов на основе кворума для предотвращения потери данных после выхода из строя сразу нескольких синхронно реплицируемых узлов. Например, теперь можно указать, что коммит должен быть подтверждён любыми К из N запасных синхронно реплицируемых серверов;
- Поддержка отслеживания (https://blog.2ndquadrant.com/traceable-commit-postgresql-10/) незавершённых коммитов - теперь можно выяснить статус недавно запущенной транзакции для восстановления после краха или обрыва соединения;
- Поддержка аутентификации SCRAM (https://ru.wikipedia.org/wiki/SCRAM) для более безопасной организации доступа по паролю;
- Многохостовый режим отказоустойчивости в libpq, при котором клиент соединяется с первым работающим хостом из заданного списка;
- Добавлен параметр "target_session_attrs", позволяющий клиенту запросить хост, доступный на запись или чтение;
- Для индексов типа Hash обеспечена поддержка репликации и повышена устойчивость к сбоям после крахов;
- Добавлен новый тип полномочий, определяющий доступ к функциям мониторинга;
- Добавлено выражение XMLTABLE (https://blog.2ndquadrant.com/xmltable-intro/), позволяющее представить XML-документ в табличном формате, что существенно упрощает разбор XML-данных, хранимых в БД;- Поддержка полнотекстового поиска для типов JSON и JSONB;
- Поддержка сжатия данных в журнале pg_receivewal;- Добавлены средства для накопления статистики по корреляции данных в разных столбцах, которая может оказаться полезной для исключения ошибочного выбора некоторых стратегий планировщиком;- Добавлена независимая от операционной системы реализация свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов; Реализация основана на libicu и идентична для Linux и Windows;
- Увеличена производительность функции SUM(), преобразования кодировок символов, выполнение выражений, группировки множеств и выполнение операций JOIN над уникальными столбцами. При выполнении аналитических запросов над большим числом строк наблюдается ускорение до 40%;
- Из нарушающих совместимость изменений отмечается переименование "xlog" в "wal", прекращение поддержки протокола FE/BE 1.0, изменение настроек по умолчанию для репликации и резервирования (pg_basebackup), прекращение поддержки значений времени (Timestamps) с плавающей запятой, удаление contrib/tsearch2 и прекращение поддержки в pg_dump баз данных от PostgreSQL 7.4 и более ранних выпусков.URL: https://www.postgresql.org/about/news/1749/
Новость: http://www.opennet.ru/opennews/art.shtml?num=46572
Один из немногих проектов, которые стоит уважать!
А какие еще?
Линукс.
болгенос
Я вот ARJ уважаю - взял и тихо помер! Не то, что всякие "bloated kernel" - тянут и тянут... видно же, что труп! Но некрофилы не сдаются и продолжают подбрасывать мощи.
Ну начались беспочвенные дифирамбы. Вот прямо таки "из немногих"? Что, в мире есть сотня хороших проектов, а остальные -- дрянь, да? И что же отличает проекты "которые стоит уважать" от остальных? Вот OpenSSL стоит уважать? А less? Или less таки дрянь?
P.S. Зашёл в тред и сразу почувствовал какой-то странный неприятный запах. Слабый, но раздражающий. Чуть позже понял -- Хабрахабром воняет.
он забыл сказать опенсорс. а реально опенсорс который можно уважать можно пересчитать по пальцам двухсотпалой ладони
Любой свободный или хотя бы открытый проект, выполняющий какую-то полезную функцию, достоин уважения. И таких проектов сотни тысяч.
можно задрать критерии так, что уважать не нужно никого. можно опустить планку так, что любой код будет вызывать умиление. я это к тому, что гражданин вылез со своим "уважать", а критериев не указал. а стало быть будет сра4.
Где найти Docker образ с наиболее полным набором PostgreSQL расширений из коробки? Например MySQL драйвер.
hub.docker.com и да мы оценили вашу тупую шутку.
Как я понимаю то что говорил Олег Бартунов что хотели добавить
● BDR — двунаправленная репликация
http://2ndquadrant.com/en/resources/bdr/
● Highly Available multi-masterНе реализовали и не войдет в PostgreSQL «10.0»
https://youtu.be/Zn5cVaTnJ4o?t=39m6s
Двунаправленная репликация, это такая конфетка на верёвочке, вроде вот ещё немного и получится, но пока ни у кого не вышло, с разумными ограничениями.И чем больше работаешь с БД и отказоустойчивостью, тем проще понять что оно не реализуется в "общем виде".
> Основные улучшения :
> - Режим логической репликации позволяющий выборочно реплицировать только заданные таблицы или использовать репликацию
> в процессе обновления до новой значительной ветки. Логическая репликация манипулирует
> логическими изменениями на уровне выполняемых операций, в то время как традиционная
> репликация работает на очень низком уровне, перенося байтовые изменения в WAL-журнале;Бедные фанатики, они столько раз рассказывали, что логическая репликация как в мускуле не нужна и только WAL является единственным кошерным способом, а тут такая подлянка. Аж интересно, что теперь сочинят.
Не боись, vacuum никуда не делся, и pg_bouncer всё так же приходится прикручивать костылями.
это же очевидно
логическая репликация как в мускуле не нужна, нужна как в постгресе :)
При штатной работе не очень нужна, а для всяких бесшовных миграций на новые версии - очень даже.
Мся,с-ка,well :) Это такой эдакий продугд в себе.
Но для склада\бухгалтерии - в принципе пойдёт (если бабло больше девать некуда).
Логическая репликация как в MySQL действительно не нужна.А хорошая - нужна :-)
memory не добавили, а обещали...
Люди подскажите плиз следующее: как можно использовать асинхронную репликацию если в случае падения мастера мы имеем не синхронный слейв который нельзя использовать как новый мастер? что используете вы асинхронную репликацию или синхронную? как догоняете слейв до мастера в случае асинхронной репликации и мастер до слейва в случае синхронной (ведь возможен вариант когда на слейв запись произошла а ответ о записе мастеру не пришел, он не записал и упал) как отслеживаете событие падения мастера? как включаете слейв мастером? как удостоверяетесь что мастер и слейв синхронны до того как пускать на них запросы?
заранее спасибо за ответы!
Первое: _это_ - "вопросы от Архитектора", а не от дба. Спросите Заказчика сколько девяток ему нужно (сколько он готов платить), это сразу сформирует горизонт планирования (и отклика системы).
Второе: Падает не только БД. Составить нужно все точки отказа. А что вы будете делать если сломается диск у пользователя и он не сможет отправить запрос к БД? А что вы будете делать если упадет канал, сетевая карта у клиентов или у сервера и т.д. (Подсказка - закрепите в ТЗ ваш вариант уровня ответственности и следуйте ему, если нужно синхронно то так и будет).
Третье: у каждой системы есть срок разумного использования - за это время за железо отвечает гарантия, за сервис вендоры. Ну а ДБА отвечает за бэкапы. (храните wal на отдельном сервере)
4: Систему мониторнига обычно используют совместно.. ну и совместно дорабатывают её под задачи.
5: В классическом постгресе есть только один мастер и много слейвов. Для начала рекомендую почитать про repmgr (настройка, промоут, фолоу)
6: Распределение запросов на мастер (чтение и запись) и слейвы (только чтение) зависит только от проекта (от нужд заказчика).По по характеру вопросов могу посоветовать почитать что такое ACID и самое главное что такое транзакция и как данные видны в паралельных транзакциях.
спасибо за repmgr, почитаем.
что такое изоляция транзакция я понимаю, причем тут это?
Это как раз то, чем отличается недосинхронизированный слейв от мастера
Ссылка на локализованную документацию актуальной версии.
https://postgrespro.ru/docs/postgresql/9.6
На случай, если кто-то не в курсе.
Требую в формате комикса с цветными картинками!
Выложите пожалуйста на ютуб
> Добавлены встроенные возможности партицирования таблиц по диапазонам значений и спискам - разбивка теперь может задаваться через выражения "PARTITION BY" и "PARTITION OF" в директиве "CREATE TABLE"Ура! Наконец можно забыть про партиционирование костыльным триггером!
Когда наконец-то прикрутят pg_repack из каробки, и чтобы автоматом можно было запускать.
Задобалось бороться с распухающими базами на сотни гигов, несмотря на автовакуумы всякие.
> - Обеспечено распараллеливание с задействованием нескольких ядер CPU таких операций, как сканирование индексов и битовых карт, выполнение запросов со слиянием таблиц (JOIN);вот хорошо же.
> - Добавлен новый тип полномочий, определяющий доступ к функциям мониторинга;
ах, как хорошо.
> - Увеличена производительность функции SUM(), преобразования кодировок символов, выполнение выражений, группировки множеств и выполнение операций JOIN над уникальными столбцами. При выполнении аналитических запросов над большим числом строк наблюдается ускорение до 40%;
годнота.
спасибо, парни. ваша работа нужна и видна.