В состав будущего выпуска СУБД PosgreSQL 9.5 будет включен (http://hlinnaka.iki.fi/2015/03/23/pg_rewind-in-postgresql-9-5/) новый полезный инструмент pg_rewind (https://github.com/vmware/pg_rewind), позволяющий существенно упростить (http://hlinnaka.iki.fi/presentations/NordicPGDay2015-pg_rewi...) процесс восстановления отказоустойчивых конфигураций серверов, после переключения на резервный сервер. В настоящее время при выходе из строя основного сервера некоторые транзакции могут не успеть перенестись на запасной сервер, в случае использования асинхронной репликации.
После возвращения в строй основного сервера возникает задача синхронизации его состояния с продолжившим работу запасным сервером, который успел накопить свою порцию изменений. После восстановления работы первичного сервера запасной сервер обычно переводится в состояние заморозки БД для бэкапа, содержимое директории с данными переносится на основной сервер и замещает старые данные остановленной БД. При этом не успевший реплицироваться хвост теряется, а процесс копирования крупных БД занимает достаточно много времени. Утилита pg_rewind пытается восстановить состояние первичного сервера по WAL-логу транзакций, перебирая их начиная с момента незадолго до сбоя, определяя изменённые данные и перенося только изменившиеся блоки. Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.
URL: http://hlinnaka.iki.fi/2015/03/23/pg_rewind-in-postgresql-9-5/
Новость: http://www.opennet.me/opennews/art.shtml?num=41900
Подскажите знающие, postgresql быстрее mysql?
смотря как готовить, но да, быстрее, надежнее и вообще лучшее
По совокупности:
- При росте БД у постгреса более предсказуемое управление данными, сноуболинг не происходит из-за особенностей ядра. Как следствие на очень малых объемах постгрес работает так же как и на больших, но это заметно только до 100-200 мб.
- Продуманная безопасность у постгресса и нет необходимости перезагружать боевую БД для получения привилегированного доступа.
- Оптимизатор в ядре разрабатывался научным сообществом (с оглядкой на мировых лидеров - таких как оракл и сайбейс), а не только программистами как у мускуля (на конференции СанДейз они очень извинялись за качество кода и алгоритмы в мускуле - так как у них энтерпрайз план и включается в код только то, что одобрено руководством, а так же фичи не принимаются если это идет в разрез с энтерпрайз планом - что и привило к расколу)
- Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса, что снимает почти всю головную боль с администраторов БД и разработчиков.
- Управление кэшем не пытающимся на себя взять функции ядра ОС, каждый делает только свою часть, но делает это отлично.
- Есть множество примеров где постгрес лучше. Только вот на хостингах он встречается реже и по тому стоит чуть-чуть дороже, что и приводит к меньшему распространению.
> Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгресаЧто, простите?
http://www.postgresql.org/docs/9.3/static/ddl-partitioning.html
Range-партиции триггером - страшный стыд.
Соглашусь с оратором. Partitioning в постгре отсутствует, в мускуле - достаточно развит и решает поставленные перед ним задачи.
> Range-партиции триггером - страшный стыд.Не триггером, а совокупностью штатных методов, главный из которых в данном случае - наследование таблиц. Чего в MySQL нет в принципе.
IF ( NEW.logdate >= DATE '2006-02-01' AND
NEW.logdate < DATE '2006-03-01' ) THEN
INSERT INTO measurement_y2006m02 VALUES (NEW.*);Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования, приходится извращаться. Даже в официальной документации.
> постгряпостгрес
> IF ( NEW.logdate >= DATE '2006-02-01' AND
> NEW.logdate < DATE
> '2006-03-01' ) THEN
> INSERT INTO measurement_y2006m02 VALUES
> (NEW.*);
> Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
> кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
> приходится извращаться. Даже в официальной документации.У постгрес просто нет синтаксиса для управления partitioning, но это не мешает ему там работать.
Mysql-дрочеры задолбали своими тупыми комментами и попытками хоть чтото положительное найти в своей недодб. Одно когда используешь его поскольку приходится, другое когда пытаетесь найти эфемерные преимущества изза неумения-нежелания вклбчить моск> IF ( NEW.logdate >= DATE '2006-02-01' AND
> NEW.logdate < DATE
> '2006-03-01' ) THEN
> INSERT INTO measurement_y2006m02 VALUES
> (NEW.*);
> Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
> кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
> приходится извращаться. Даже в официальной документации.
Предлагаю обсуждать партиции с теми кому их приходится создавать и поддерживать. В оракле создайте доп. рейндж партицию или расширте набор хеш-партиций - удобно? В мускуле добавте гранулярности партициям или наследуйте другие условия на субпартиции. ТО, что механизм в явном виде использует более длинный синтаксис (только больше набирать на клавиатуре, если не умеете автоматизировать) не повод ругать очень ГИБКУЮ систему.
Експлейн на партицированые данные покажет реальную статистику и использует отдельные гистограммы. Если у вас реально отношение вставок к выборкам разбалансированно возможно стоит трезво оценить решение и использовать nosql + etl к примеру.
> партицирование на сегодняшний день самое лучше и продуманное у постгреса,Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.
>> партицирование на сегодняшний день самое лучше и продуманное у постгреса,
> Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.Это не совсем так.
> Подскажите знающие, postgresql быстрее mysql?http://www.databasesoup.com/2015/02/running-with-scissors-mo... Намного!
Какое отношение твой вопрос имеет к теме новости?
> Подскажите знающие, postgresql быстрее mysql?Если вам сказать "да, быстрее", вы броситесь его изучать и переписывать сайты с mysql на postgres?
Postgre помощнее будет.
postgres
Не быстрее не надежнее и не лучше, все зависит только от того как готовить.
Да постгрес хорош. И академичен и развивается.
А еще меня попросили, почистить место. Там постгрес статистику с приборов в сушильном цехе хранит. 8 лет назад был запущен, так и работает.
> запасной сервер переводится в состояние заморозки БД для бэкапаКакое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?
>> запасной сервер переводится в состояние заморозки БД для бэкапа
> Какое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?SELECT pg_start_backup('label');
http://www.postgresql.org/docs/9.1/static/continuous-archivi...
--
Там неаверху была попытка изложить "что было" vs "что стало". Вот здесь http://hlinnaka.iki.fi/2015/03/23/pg_rewind-in-postgresql-9-5/ , imho, чуть понятнее.
> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.с последнего checkpoint скорее всего, а не commit.
>> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.
> с последнего checkpoint скорее всего, а не commit.Нет, коммита. По WAL-логам.
И нет, не с "последней зафиксированной", а с последней _общей точки историй двух серверов.
Слайд#25:
Start recovery from the point of divergence, not
some later checkpoint.[И судя по этому "not ... checkpoint" вплоть до откатывания чекпоинтов, не доехавших до нового мастера.]