The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Для PostgreSQL подготовлен инструмент ресинхронизации pg_rewind"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Для PostgreSQL подготовлен инструмент ресинхронизации pg_rewind"  +/
Сообщение от opennews on 24-Мрт-15, 17:31 
В состав будущего выпуска СУБД 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.dev/opennews/art.shtml?num=41900

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  –3 +/
Сообщение от czarj on 24-Мрт-15, 17:31 
Подскажите знающие, postgresql быстрее mysql?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +8 +/
Сообщение от takem on 24-Мрт-15, 17:40 
смотря как готовить, но да, быстрее, надежнее и вообще лучшее
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +6 +/
Сообщение от ъ on 24-Мрт-15, 17:56 
По совокупности:
- При росте БД у постгреса более предсказуемое управление данными, сноуболинг не происходит из-за особенностей ядра. Как следствие на очень малых объемах постгрес работает так же как и на больших, но это заметно только до 100-200 мб.
- Продуманная безопасность у постгресса и нет необходимости перезагружать боевую БД для получения привилегированного доступа.
- Оптимизатор в ядре разрабатывался научным сообществом (с оглядкой на мировых лидеров - таких как оракл и сайбейс), а не только программистами как у мускуля (на конференции СанДейз они очень извинялись за качество кода и алгоритмы в мускуле - так как у них энтерпрайз план и включается в код только то, что одобрено руководством, а так же фичи не принимаются если это идет в разрез с энтерпрайз планом - что и привило к расколу)
- Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса, что снимает почти всю головную боль с администраторов БД и разработчиков.
- Управление кэшем не пытающимся на себя взять функции ядра ОС, каждый делает только свою часть, но делает это отлично.
- Есть множество примеров где постгрес лучше. Только вот на хостингах он встречается реже и по тому стоит чуть-чуть дороже, что и приводит к меньшему распространению.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

8. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +1 +/
Сообщение от Аноним (??) on 24-Мрт-15, 20:51 
> Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса

Что, простите?

http://www.postgresql.org/docs/9.3/static/ddl-partitioning.html

Range-партиции триггером - страшный стыд.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 24-Мрт-15, 22:44 
Соглашусь с оратором. Partitioning в постгре отсутствует, в мускуле - достаточно развит и решает поставленные перед ним задачи.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним аля on 25-Мрт-15, 07:36 
> Range-партиции триггером - страшный стыд.

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 16:51 
    IF ( NEW.logdate >= DATE '2006-02-01' AND
         NEW.logdate < DATE '2006-03-01' ) THEN
        INSERT INTO measurement_y2006m02 VALUES (NEW.*);

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

16. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 19:43 
> постгря

постгрес

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 19:45 
>     IF ( NEW.logdate >= DATE '2006-02-01' AND
>          NEW.logdate < DATE
> '2006-03-01' ) THEN
>         INSERT INTO measurement_y2006m02 VALUES
> (NEW.*);
> Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
> кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
> приходится извращаться. Даже в официальной документации.

У постгрес просто нет синтаксиса для управления partitioning, но это не мешает ему там работать.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +3 +/
Сообщение от asdasd on 26-Мрт-15, 10:33 
Mysql-дрочеры задолбали своими тупыми комментами и попытками хоть чтото положительное найти в своей недодб. Одно когда используешь его поскольку приходится, другое когда пытаетесь найти эфемерные преимущества изза неумения-нежелания вклбчить моск

>     IF ( NEW.logdate >= DATE '2006-02-01' AND
>          NEW.logdate < DATE
> '2006-03-01' ) THEN
>         INSERT INTO measurement_y2006m02 VALUES
> (NEW.*);
> Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
> кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
> приходится извращаться. Даже в официальной документации.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

23. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +1 +/
Сообщение от ъ on 27-Мрт-15, 17:52 
Предлагаю обсуждать партиции с теми кому их приходится создавать и поддерживать. В оракле создайте доп. рейндж партицию или расширте набор  хеш-партиций - удобно? В мускуле добавте гранулярности партициям или наследуйте другие условия на субпартиции. ТО, что механизм в явном виде использует более длинный синтаксис (только больше набирать на клавиатуре, если не умеете автоматизировать) не повод ругать очень ГИБКУЮ систему.
Експлейн на партицированые данные покажет реальную статистику и использует отдельные гистограммы. Если у вас реально отношение вставок к выборкам разбалансированно возможно стоит трезво оценить решение и использовать nosql + etl к примеру.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 11:57 
> партицирование на сегодняшний день самое лучше и продуманное у постгреса,

Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

15. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 19:42 
>> партицирование на сегодняшний день самое лучше и продуманное у постгреса,
> Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.

Это не совсем так.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

6. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +1 +/
Сообщение от Andrey Mitrofanov on 24-Мрт-15, 18:15 
> Подскажите знающие, postgresql быстрее mysql?

http://www.databasesoup.com/2015/02/running-with-scissors-mo... Намного!

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

13. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 19:37 
Какое отношение твой вопрос имеет к теме новости?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

24. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от XoRe (ok) on 30-Мрт-15, 01:26 
> Подскажите знающие, postgresql быстрее mysql?

Если вам сказать "да, быстрее", вы броситесь его изучать и переписывать сайты с mysql на postgres?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  –1 +/
Сообщение от dkg on 24-Мрт-15, 17:44 
Postgre помощнее будет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 19:38 
postgres
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  –7 +/
Сообщение от amix email(ok) on 24-Мрт-15, 17:47 
Не быстрее не надежнее и не лучше, все зависит только от того как готовить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от o on 24-Мрт-15, 18:20 
Да постгрес хорош. И академичен и развивается.
А еще меня попросили, почистить место. Там постгрес статистику с приборов в сушильном цехе хранит. 8 лет назад был запущен, так и работает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 20:05 
> запасной сервер переводится в состояние заморозки БД для бэкапа

Какое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Andrey Mitrofanov on 26-Мрт-15, 09:57 
>> запасной сервер переводится в состояние заморозки БД для бэкапа
> Какое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?

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, чуть понятнее.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

19. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Аноним (??) on 25-Мрт-15, 20:08 
> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.

с последнего checkpoint скорее всего, а не commit.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Для PostgreSQL подготовлен инструмент ресинхронизации pg_rew..."  +/
Сообщение от Andrey Mitrofanov on 26-Мрт-15, 10:14 
>> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.
> с последнего checkpoint скорее всего, а не commit.

Нет, коммита. По WAL-логам.

И нет, не с "последней зафиксированной", а с последней _общей точки историй двух серверов.

Слайд#25:

Start recovery from the point of divergence, not
some later checkpoint.

[И судя по этому "not ... checkpoint" вплоть до откатывания чекпоинтов, не доехавших до нового мастера.]

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру