Рубрика «postgresql» - 21

в 14:13, , рубрики: dbms, postgres, postgresql, rdbms, базы данных, Блог компании Postgres Professional, СУБД

Дайджест новостей из мира PostgreSQL. Выпуск №16 - 1

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Главная новость июня

EnterpriseDB приобретена инвестиционным фондом Great Hill Partners. Сумма сделки не разглашается. Майкл Стоунбрейкер назначен техническим советником. Энди Палмер вошел в совет директоров EDB. Он известный ИТ-инвестор, сооснователь Vertica и автор главы в книге Making Databases Work: The Pragmatic Wisdom of Michael Stonebraker. Great Hill Partners — частный (непубличный) фонд, управляющий $2.7 млрд. Событие не менее впечатляющее, чем недавняя покупка Citus Microsoft-ом: из 5 участников Core Team двое сотрудники EDB.

Релизы

PostgreSQL 11.4, 10.9, 9.6.14, 9.5.18, 9.4.23 и 12 Beta 2

Этих релизов ждали не из-за новых фич, а из-за того, что надо было закрывать обнаруженную дырку в безопасности под кодовым названием CVE-2019-10164. Любой прошедший проверку при аутентификации по методу scram-sha-256 пользователь мог переполнить буфер в стеке, сменяя свой пароль на специально сконструированную строку. Этим способом можно было не только уронить сервер, но и выполнить произвольный код от имени пользователя ОС, запускающего PostgreSQL.

Подобная возможность переполнения существовала и в libpq, и эксплуатируя её, подставной сервер мог уронить клиентское приложение или выполнить коварный код на клиенте от имени пользователя, запускавшего это приложение.

Эта уязвимость проявилась только в относительно новых версиях PostgreSQL: 10 и выше, когда появилась SCRAM-аутентификация. На сайте сообщества можно увидеть «особую благодарность» Александру Лахину (Postgres Professional), который обнаружил проблему.

Можно почитать статью на эту тему: eVOL Monkey. Who's affected and how to protect your systems.

Postgres Pro Standard 11.4.1, 10.9.1, 9.6.14.1, 9.5.17.1 и Postgres Pro Enterprise 11.4.1

В этих версиях дыра в безопасности уже закрыта. Об этом и о других багфиксах можно прочитать в документации к соответствующей версии. Читать полностью »

в 10:00, , рубрики: benchmark, kernel, linux, postgresql, Настройка Linux

Сравнительное тестирование работы PostgreSQL с большими страницами Linux - 1 Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Это все о получении правильной конфигурации для вашего приложения и рабочей нагрузки. Как и любая другая база данных, PostgreSQL использует ядро ​​Linux для оптимальной конфигурации. Плохо настроенные параметры могут привести к снижению производительности. Поэтому важно, чтобы вы измеряли производительность базы данных после каждого сеанса настройки, чтобы избежать снижения производительности. В одной из моих предыдущих публикаций, «Настройка параметров ядра Linux для оптимизации PostgreSQL», я описал некоторые наиболее полезные параметры ядра Linux и то, как они могут помочь вам повысить производительность базы данных. Теперь я собираюсь поделиться своими результатами тестов после настройки больших страниц Linux с другой рабочей нагрузкой PostgreSQL. Я выполнил исчерпывающий набор тестов для разных размеров загрузки PostgreSQL и одновременного количества клиентов.

Машина для тестирования

  • Supermicro server:
    • Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz
    • 2 sockets / 28 cores / 56 threads
    • Memory: 256GB of RAM
    • Storage: SAMSUNG SM863 1.9TB Enterprise SSD
    • Filesystem: ext4/xfs
  • OS: Ubuntu 16.04.4, kernel 4.13.0-36-generic
  • PostgreSQL: version 11

Читать полностью »

в 4:49, , рубрики: linux, linux kernel, optimization, postgresql, tuning, Настройка Linux

Настройка параметров ядра Linux для оптимизации PostgreSQL - 1 Оптимальная производительность PostgreSQL зависит от правильно определенных параметров операционной системы. Плохо настроенные параметры ядра ОС могут привести к снижению производительности сервера базы данных. Поэтому обязательно, чтобы эти параметры были настроены в соответствии с сервером базы данных и его рабочей нагрузкой. В этом посте мы обсудим некоторые важные параметры ядра Linux, которые могут повлиять на производительность сервера базы данных и способы их настройки.

SHMMAX / SHMALL

SHMMAX — это параметр ядра, используемый для определения максимального размера одного сегмента разделяемой памяти (shared memory), который может выделить процесс Linux. До версии 9.2 PostgreSQL использовал System V (SysV), для которой требуется настройка SHMMAX. После 9.2 PostgreSQL переключился на разделяемую память POSIX. Так что теперь требуется меньше байтов разделяемой памяти System V.

До версии 9.3 SHMMAX был наиболее важным параметром ядра. Значение SHMMAX задается в байтах.
Читать полностью »

в 12:32, , рубрики: open source, postgresql, time series, time series database, tsdb, zabbix, zabbix 4.2, zabbix мониторинг, Администрирование баз данных, Блог компании Zabbix, системное администрирование

Каждая система мониторинга сталкивается с тремя видами проблем, связанных с производительностью.

Во-первых, хорошая система мониторинга должна очень быстро получать, обрабатывать и записывать поступающие извне данные. Счёт идёт на микросекунды. Навскидку это может показаться неочевидным, но когда система становится достаточно большой, все эти доли секунд суммируются, превращаясь в хорошо заметные задержки.

image
Читать полностью »

в 9:27, , рубрики: continuous replication, devops, postgresql, replication, slonic, Блог компании Southbridge, Серверное администрирование, системное администрирование

Непрерывная репликация из старой в новую версию PostgreSQL с помощью Slony - 1

Нативная потоковая репликация в PostgreSQL работает только между серверами с одинаковой основной версией. О логической репликации мы говорили в предыдущем посте. Мы увидели, как логическая репликация помогает перенести данные из одной версии PostgreSQL в другую. Но логическая репликация подходит только для поддерживаемых версий PostgreSQL, например, для PostgreSQL 9.4 и PostgreSQL 11. Что делать с версиями до 9.4? Использовать Slony-I.

Используйте репликацию с помощью Slony-I, чтобы перенести данные из старых баз в последнюю версию PostgreSQL. Что такое Slony и как он работает?

Читать полностью »

в 15:18, , рубрики: buffer cache, buffer pool, postgresql, sql, wal, write-ahead log, Блог компании Postgres Professional

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

Этот цикл будет состоять из четырех частей:

  • Буферный кеш (эта статья);
  • Журнал предзаписи — как устроен и как используется при восстановлении;
  • Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
  • Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Зачем нужно журналирование?

В процессе работы часть данных, с которыми имеет дело СУБД, хранится в оперативной памяти и записывается на диск (или на другой энергонезависимый носитель) отложенным образом. Чем реже это происходит, тем меньше ввод-вывод и тем быстрее работает система.

Но что произойдет в случае сбоя, например, при выключении электропитания или при ошибке в коде СУБД или операционной системы? Все содержимое оперативной памяти будет потеряно, а останутся лишь данные, записанные на диск (при некоторых видах сбоев может пострадать и диск, но в этом случае поможет лишь резервная копия). В принципе можно организовать ввод-вывод таким образом, чтобы данные на диске всегда поддерживались в согласованном состоянии, но это сложно и не слишком эффективно (насколько я знаю, только Firebird пошел таким путем).

Обычно же — в том числе и в PostgreSQL — данные, записанные на диск, оказываются несогласованными и при восстановлении после сбоя требуются специальные действия, чтобы согласованность восстановить. Журналирование — тот самый механизм, который делает это возможным.
Читать полностью »

в 10:10, , рубрики: .net, 1c, 1c 8.3, CentOS, centos 7, linux, Microsoft SQL Server, postgresql, sql, sql server, windows, Windows Server, windows server 2012 r2, администрирование 1с, Администрирование баз данных, Администрирование БД, гилев

Цели и требования к тестированию «1С Бухгалтерии»

Основной целью проводимого тестирования является сравнение поведения системы 1С на двух разных СУБД при прочих одинаковых условиях. Т.е. конфигурация баз данных 1С и первоначальная заполненность данными должны быть одинаковыми при проведении каждого тестирования.
Основными параметрами, которые должны быть получены при тестировании:

  • Время выполнения каждого теста (снимается отделом Разработки 1С)
  • Нагрузка на СУБД и серверное окружение во время выполнения теста снимается- администраторами СУБД, а также по серверному окружению системными администраторами

Тестирование системы 1С должно выполняться с учетом клиент-серверной архитектуры, поэтому необходимо произвести полноценную эмуляцию работы пользователя или нескольких пользователей в системе с отработкой ввода информации в интерфейсе и сохранением этой информации в базе данных. При этом, необходимо, чтобы большой объем периодической информации был разнесен по большому отрезку времени для создания итогов в регистрах накопления.

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

Описание настроек и характеристик тестируемых сред

Мы в компании Fortis решили перепроверить результаты, в том числе с помощью известного теста Гилева.

Также нас подстегнуло к тестированию в том числе и некоторые публикации по результатам изменения производительности при переходе от MS SQL Server к PostgreSQL. Такие как: 1С Батл: PostgreSQL 9,10 vs MS SQL 2016.
Читать полностью »

в 11:16, , рубрики: benchmark, highload, postgresql, перевод с английского

Данная статья является переводом оригинальной статьи Martin Kováčik «PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE» https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

Перевод

В этом посте я собираюсь показать результаты тестов недавно выпущенного PostgreSQL 10.1. Я проверил БД на этих ОС (все 64-битные):

  • Ubuntu 16.04, ядро 4.10.0-38-generic
  • openSUSE 42.3, ядро 4.4.87-25-default
  • CentOS 7.4, ядро 3.10.0-693.2.2.el7.x86_64
  • Debian 9.2, ядро 4.9.0-4-amd64
  • FreeBSD 11.1

Читать полностью »

в 11:18, , рубрики: (:, postgresql, sql, Блог компании Postgres Professional, Занимательные задачки, Радио SQL

В эфире опять Радио SQL! Сегодня у нас совсем краткий выпуск, посвящённый подведению итогов решения задачки участниками хабросообщества. Я обещал разыграть небольшой приз, так что подвести итоги лучше небольшой, но всё же статьёй. Дописать строчку в оригинальную статью (что я, впрочем, тоже сделал) — было явно недостаточно, заинтересованные лица могут пропустить такое подведение итогов. Поэтому подстраивайте свои ложементы и вытягивайте омматофоры, мы начинаем!

SQL: задача о рабочем времени: разбор полётов - 1

Читать полностью »

в 7:24, , рубрики: devops, logical replication, postgresql, replication, Блог компании Southbridge, Серверное администрирование, системное администрирование

Логическая репликация между версиями PostgreSQL - 1

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

В предыдущих статьях мы уже говорили о методах обновления PostgreSQL (Обновление версии PostgreSQL с помощью pg_dumpall и Обновление версии PostgreSQL с помощью pg_dump/pg_restore) в рамках серии Обновление или миграция старых версий PostgreSQL в новые. Но оба этих метода не исключают простоя.

Читать полностью »

1...10...202122...3040...76
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js