В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

PostgreSQL + 1C + Linux

1724 membersпожаловаться на группу
2020 October 21

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
и кстати, Zfs тут не всегда спасёт, сбой может быть не на уровне ФС, а на уровне ОС
Вот цитата из документации : это необходимо, потому что запись страницы, прерванная при сбое операционной системы, может выполниться частично, и на диске окажется страница, содержащая смесь старых данных с новыми.
источник
08:20пожаловаться#1

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
в общем тут надо быть ооочень аккуратным
источник
08:20пожаловаться#2

LK

L K in PostgreSQL + 1C + Linux
Антон Дорошкевич
и кстати, Zfs тут не всегда спасёт, сбой может быть не на уровне ФС, а на уровне ОС
Вот цитата из документации : это необходимо, потому что запись страницы, прерванная при сбое операционной системы, может выполниться частично, и на диске окажется страница, содержащая смесь старых данных с новыми.
А вы zfs используете?
источник
08:27пожаловаться#3

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
нет, только ext4
на моих нагрузках zfs сильно проигрывает как его не настраивай
источник
08:28пожаловаться#4

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
только спорить про выбор ФС не буду)))
у всех свои причины и сценарии)
источник
08:29пожаловаться#5

LK

L K in PostgreSQL + 1C + Linux
Понятно.
источник
08:30пожаловаться#6

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
L K
А recordsize=8k ?
для файлов БД - 16к, для WAL-файлов 128k
источник
09:37пожаловаться#7

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
Антон Дорошкевич
отключение full_page_writes - крайне рискованно
отключение synchronous_commit - приводит к хорошему росту скорости, обычно кратному и не так рискованно
Отключить оба параметра - тогда и fsync наверное тоже отключить можно, так как уже ни о какой защите после сбоя говорить не приходится, тут чисто скорость
Выбор сложный, но зато он есть
Антон, вы работали с ZFS? Что такое ZIL понимаете?
источник
09:37пожаловаться#8

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
Антон Дорошкевич
и кстати, Zfs тут не всегда спасёт, сбой может быть не на уровне ФС, а на уровне ОС
Вот цитата из документации : это необходимо, потому что запись страницы, прерванная при сбое операционной системы, может выполниться частично, и на диске окажется страница, содержащая смесь старых данных с новыми.
ZFS - это постгрес на уровне файловой системы (ОС). Тут есть и журнал для записи, и транзакции. И CoW.
источник
09:39пожаловаться#9

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
Да, я понимаю
источник
09:39пожаловаться#10

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
Поэтому и пишу что каждый свой выбор сделает
источник
09:40пожаловаться#11

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
Когда вы включаете full_page_writes, то получается масло масленное. Вам сама ФС обеспечивает необходимый уровень надёжности. Я не буду убеждать), но сами разработчики PG допускают выключение full_page_writes на ZFS. Я не думаю что они это делают неосознанно)
источник
09:40пожаловаться#12

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
Но пренебрегать средствами защиты данных субд опасно и надо чётко понимать что может случится и в каком случае
источник
09:40пожаловаться#13

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
Сергей Голод
Когда вы включаете full_page_writes, то получается масло масленное. Вам сама ФС обеспечивает необходимый уровень надёжности. Я не буду убеждать), но сами разработчики PG допускают выключение full_page_writes на ZFS. Я не думаю что они это делают неосознанно)
В целом - согласен
источник
09:41пожаловаться#14

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
Именно на zfs наверное можно рискнуть
источник
09:41пожаловаться#15

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
L K
А во сколько раз взлетают результаты теста pg_bench по записи?
полноценного тестирования не делал. Но вот сейчас есть под рукой свободный сервер с ZFS и PG12. Могу на нём кстати проверить тесты с разными значениями параметров
источник
09:41пожаловаться#16

АД

Антон Дорошкевич... in PostgreSQL + 1C + Linux
Сергей Голод
полноценного тестирования не делал. Но вот сейчас есть под рукой свободный сервер с ZFS и PG12. Могу на нём кстати проверить тесты с разными значениями параметров
Было бы отлично
источник
09:43пожаловаться#17

LK

L K in PostgreSQL + 1C + Linux
Сергей Голод
полноценного тестирования не делал. Но вот сейчас есть под рукой свободный сервер с ZFS и PG12. Могу на нём кстати проверить тесты с разными значениями параметров
Здорово былобы сделать тесты
А как у Вас реализовано zfs?
На хосте pve и/или в vm kvm?
Когда реализуете разные recordsize?
источник
09:46пожаловаться#18

RS

Roman Syuzyov in PostgreSQL + 1C + Linux
Антон Дорошкевич
Именно на zfs наверное можно рискнуть
Вот тут самое интересное: вчера хорошенько все осмыслил и получается дополнительных (по сравнению с synchronous_commit=off) рисков действительно нет - zfs либо запишет данные целиком и корректно, либо мы совсем последнюю операцию не увидим, в любом случае консистентность не будет нарушена. Ну а вероятность потери нескольких транзакций перед крахом я уже принял, когда synchronous_commit отключал.
источник
09:49пожаловаться#19

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
L K
Здорово былобы сделать тесты
А как у Вас реализовано zfs?
На хосте pve и/или в vm kvm?
Когда реализуете разные recordsize?
конечно на хосте. Внутри ВМ zfs смысла не имеет, я бы даже НЕ рекомендовал так делать
источник
09:52пожаловаться#20