The OpenNET Project / Index page

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

Для PostgreSQL подготовлен инструмент ресинхронизации pg_rewind

24.03.2015 16:37

В состав будущего выпуска СУБД PostgreSQL 9.5 будет включен новый полезный инструмент pg_rewind, позволяющий существенно упростить процесс восстановления отказоустойчивых конфигураций серверов, после переключения на резервный сервер. В настоящее время при выходе из строя основного сервера некоторые транзакции могут не успеть перенестись на запасной сервер, в случае использования асинхронной репликации.

После возвращения в строй основного сервера возникает задача синхронизации его состояния с продолжившим работу запасным сервером, который успел накопить свою порцию изменений. После восстановления работы первичного сервера его начинка обычно создаётся заново, с помощью взятия копии с работающего резервного сервера - запасной сервер переводится в состояние заморозки БД для бэкапа, а содержимое директории с данными переносится на основной сервер. При этом не успевший реплицироваться хвост теряется, а процесс копирования крупных БД занимает достаточно много времени. Утилита pg_rewind пытается восстановить состояние первичного сервера по WAL-логу транзакций, перебирая их начиная с момента незадолго до сбоя, определяя изменённые данные и перенося только изменившиеся блоки. Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.

  1. Главная ссылка к новости (http://hlinnaka.iki.fi/2015/03...)
  2. Организация горячего бэкапа PostgreSQL
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41900-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, czarj (?), 17:31, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Подскажите знающие, postgresql быстрее mysql?
     
     
  • 2.2, takem (?), 17:40, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +8 +/
    смотря как готовить, но да, быстрее, надежнее и вообще лучшее
     
  • 2.5, ъ (?), 17:56, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    По совокупности:
    - При росте БД у постгреса более предсказуемое управление данными, сноуболинг не происходит из-за особенностей ядра. Как следствие на очень малых объемах постгрес работает так же как и на больших, но это заметно только до 100-200 мб.
    - Продуманная безопасность у постгресса и нет необходимости перезагружать боевую БД для получения привилегированного доступа.
    - Оптимизатор в ядре разрабатывался научным сообществом (с оглядкой на мировых лидеров - таких как оракл и сайбейс), а не только программистами как у мускуля (на конференции СанДейз они очень извинялись за качество кода и алгоритмы в мускуле - так как у них энтерпрайз план и включается в код только то, что одобрено руководством, а так же фичи не принимаются если это идет в разрез с энтерпрайз планом - что и привило к расколу)
    - Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса, что снимает почти всю головную боль с администраторов БД и разработчиков.
    - Управление кэшем не пытающимся на себя взять функции ядра ОС, каждый делает только свою часть, но делает это отлично.
    - Есть множество примеров где постгрес лучше. Только вот на хостингах он встречается реже и по тому стоит чуть-чуть дороже, что и приводит к меньшему распространению.
     
     
  • 3.8, Аноним (-), 20:51, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса

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

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

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

     
     
  • 4.9, Аноним (-), 22:44, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Соглашусь с оратором. Partitioning в постгре отсутствует, в мускуле - достаточно развит и решает поставленные перед ним задачи.
     
  • 4.10, Аноним аля (?), 07:36, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Range-партиции триггером - страшный стыд.

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

     
     
  • 5.12, Аноним (-), 16:51, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
        IF ( NEW.logdate >= DATE '2006-02-01' AND
             NEW.logdate < DATE '2006-03-01' ) THEN
            INSERT INTO measurement_y2006m02 VALUES (NEW.*);

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

     
     
  • 6.16, Аноним (-), 19:43, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > постгря

    постгрес

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

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

     
  • 6.22, asdasd (?), 10:33, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Mysql-дрочеры задолбали своими тупыми комментами и попытками хоть чтото положительное найти в своей недодб. Одно когда используешь его поскольку приходится, другое когда пытаетесь найти эфемерные преимущества изза неумения-нежелания вклбчить моск

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

     
  • 4.23, ъ (?), 17:52, 27/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Предлагаю обсуждать партиции с теми кому их приходится создавать и поддерживать. В оракле создайте доп. рейндж партицию или расширте набор  хеш-партиций - удобно? В мускуле добавте гранулярности партициям или наследуйте другие условия на субпартиции. ТО, что механизм в явном виде использует более длинный синтаксис (только больше набирать на клавиатуре, если не умеете автоматизировать) не повод ругать очень ГИБКУЮ систему.
    Експлейн на партицированые данные покажет реальную статистику и использует отдельные гистограммы. Если у вас реально отношение вставок к выборкам разбалансированно возможно стоит трезво оценить решение и использовать nosql + etl к примеру.
     
  • 3.11, Аноним (-), 11:57, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > партицирование на сегодняшний день самое лучше и продуманное у постгреса,

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

     
     
  • 4.15, Аноним (-), 19:42, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> партицирование на сегодняшний день самое лучше и продуманное у постгреса,
    > Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.

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

     
  • 2.6, Andrey Mitrofanov (?), 18:15, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Подскажите знающие, postgresql быстрее mysql?

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

     
  • 2.13, Аноним (-), 19:37, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Какое отношение твой вопрос имеет к теме новости?
     
  • 2.24, XoRe (ok), 01:26, 30/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Подскажите знающие, postgresql быстрее mysql?

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

     

  • 1.3, dkg (?), 17:44, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Postgre помощнее будет.
     
     
  • 2.14, Аноним (-), 19:38, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    postgres
     

  • 1.4, amix (ok), 17:47, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Не быстрее не надежнее и не лучше, все зависит только от того как готовить.
     
  • 1.7, o (?), 18:20, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да постгрес хорош. И академичен и развивается.
    А еще меня попросили, почистить место. Там постгрес статистику с приборов в сушильном цехе хранит. 8 лет назад был запущен, так и работает.
     
  • 1.18, Аноним (-), 20:05, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > запасной сервер переводится в состояние заморозки БД для бэкапа

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

     
     
  • 2.20, Andrey Mitrofanov (?), 09:57, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> запасной сервер переводится в состояние заморозки БД для бэкапа
    > Какое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?

    SELECT pg_start_backup('label');

    http://www.postgresql.org/docs/9.1/static/continuous-archiving.html#BACKUP-BA

    --
    Там неаверху была попытка изложить "что было" vs "что стало". Вот здесь http://hlinnaka.iki.fi/2015/03/23/pg_rewind-in-postgresql-9-5/ , imho, чуть понятнее.

     

  • 1.19, Аноним (-), 20:08, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.

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

     
     
  • 2.21, Andrey Mitrofanov (?), 10:14, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.
    > с последнего checkpoint скорее всего, а не commit.

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

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

    Слайд#25:

    [CODE]Start recovery from the point of divergence, not
    some later checkpoint.[/CODE]

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

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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