форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Для 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 (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 | Индекс форумов | Темы | Пред. тема | След. тема