MM
при чём тут мастер-мастер?
Чтобы, если упало железо, сменил адрес сервера и летишь дальше. А потом по-свободе расковыриваешь то, что рухнуло.
Size: a a a
2021 February 24
VY
Чтобы, если упало железо, сменил адрес сервера и летишь дальше. А потом по-свободе расковыриваешь то, что рухнуло.
1. для этого не нужен мастер-мастер
2. что будете делать, если вся сеть упадёт?
2. что будете делать, если вся сеть упадёт?
MM
Как-то на 9.2 (если память не изменяет) была репликация и в один момент ушли на слейва из-за сгоревшего мастера. Потом были какие-то проблемы, что старого мастера так и не смогли запромоутить.... Но блин, было давно и уже плохо помню.
Z
репликацию для бекапа нельзя. только как доп. средство. если кто то сделает DROP - отреплицируется везде.
MM
1. для этого не нужен мастер-мастер
2. что будете делать, если вся сеть упадёт?
2. что будете делать, если вся сеть упадёт?
ну, если ставить второй сервер, то его можно поставить, например, в другом подразделении того же OVH.
MM
Zheka_13
репликацию для бекапа нельзя. только как доп. средство. если кто то сделает DROP - отреплицируется везде.
ну и это как-бы да....
AN
А можно я вылезу с вопросом про бекапы? Есть сервер, на нем лежит 2 БД. Продакшен и тест. Общий размер на FS - 72 гига. Продакшен - из них занимает 42Гб. В сжатом виде архив от pg_dump прода занимает около 5.5Гб. Снятие дампов через pg_dump очень не нравится, так как разворачивается до 40 минут. Сами данные восстанавливаются относительно быстро, а вот индексы, и форинкеи - это долго. Сейчас дамп снимается раз в сутки, но это как-то слишком редко. Хотелось бы чаще и быстрее в плане восстановления, так как ждать разворота БД такое время слишком критично. Новые данные поступают в систему почти непрерывным потоком. RAM на машинке - 128Гб, хранилище - зеркало на SSD
Pg_basebackup pg_probackup и т д.
Y@
Ребят, всем привет!)
Есть интересная задача, отсортировать выдачу рандомно но с участием
сида ( есть ключ UUID при котором отсортированные данные должны приходить в том же порядке )
Может кто-то подскажет в какую сторону копать?)
Есть интересная задача, отсортировать выдачу рандомно но с участием
сида ( есть ключ UUID при котором отсортированные данные должны приходить в том же порядке )
Может кто-то подскажет в какую сторону копать?)
NP
коллеги, подскажите... ожидание BufFileWrite при селекте - оно о чем?
МШ
А можно я вылезу с вопросом про бекапы? Есть сервер, на нем лежит 2 БД. Продакшен и тест. Общий размер на FS - 72 гига. Продакшен - из них занимает 42Гб. В сжатом виде архив от pg_dump прода занимает около 5.5Гб. Снятие дампов через pg_dump очень не нравится, так как разворачивается до 40 минут. Сами данные восстанавливаются относительно быстро, а вот индексы, и форинкеи - это долго. Сейчас дамп снимается раз в сутки, но это как-то слишком редко. Хотелось бы чаще и быстрее в плане восстановления, так как ждать разворота БД такое время слишком критично. Новые данные поступают в систему почти непрерывным потоком. RAM на машинке - 128Гб, хранилище - зеркало на SSD
https://ru-postgres.livejournal.com/66359.html
Немного устарела по wal-e, wal-g, но для пинка в нужном направлении, я думаю, пойдёт.
Немного устарела по wal-e, wal-g, но для пинка в нужном направлении, я думаю, пойдёт.
MM
Вопрос тупой конечно, но как на счет выставления флага бекапа, копирования фс и снятия флага? Это будет быстро? Ведь восстановиться - просто раскатать tar ?
MM
типа такого
VY
https://ru-postgres.livejournal.com/66359.html
Немного устарела по wal-e, wal-g, но для пинка в нужном направлении, я думаю, пойдёт.
Немного устарела по wal-e, wal-g, но для пинка в нужном направлении, я думаю, пойдёт.
wal-e я бы не рассматривал, поимел с ним проблему на 13-й версии сразу после миграции:
новые бэкапы битые оказались, восстановиться не смог ни из одного. в причинах не разбирался, срочно менял систему (
новые бэкапы битые оказались, восстановиться не смог ни из одного. в причинах не разбирался, срочно менял систему (
pgbackrest )XZ
Коллеги, доброго времени.
Вероятно в этом чате есть гуру и эксперты,
которые помогут подсказать направление куда копать, в какую сторону,
заранее спасибо!
Получаем вот такую ошибку:
org.postgresql.util.PSQLException: ERROR: out of memory
Подробности: Failed on request of size 8 in memory context "Subplan HashTable Temp Context".
В одной из сессий происходит выполнение составного запроса типа select столбцы, а также подселекты с count(*) как виртуальные столбцы из связки представлений и таблиц с условиями,
в условиях есть сравнение значений в подселектами с count(*).
При этом Postgres ( этот процесс ) съедает всю память на сервере (до 32 GB) и ввиду этого отстреливает всех пользователей с ошибкой:
[i]WARNING: terminating connection because of crash of another server process
The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
Детали, если важны:
1. Запрос выполняется успешно практически всегда без последствий, исключение до 10% - оно печальное, как описано выше.
2. Редакция PostgreSQL — свободная, версии 12.3
3. Платформа Windows 2008/2016
4. Данных в связке из представлений и таблиц в строках не так много, не если учитывать условия, то 300 000, 180 000, 3 000 000, и 50 строк, если с условиями – результат до 5000 строк
Вопрос - как лечить такую ошибку?
Спасибо,
P.S. в дополнительной информации о данных ограничены со стороны информационной безопасности.
Вероятно в этом чате есть гуру и эксперты,
которые помогут подсказать направление куда копать, в какую сторону,
заранее спасибо!
Получаем вот такую ошибку:
org.postgresql.util.PSQLException: ERROR: out of memory
Подробности: Failed on request of size 8 in memory context "Subplan HashTable Temp Context".
В одной из сессий происходит выполнение составного запроса типа select столбцы, а также подселекты с count(*) как виртуальные столбцы из связки представлений и таблиц с условиями,
в условиях есть сравнение значений в подселектами с count(*).
При этом Postgres ( этот процесс ) съедает всю память на сервере (до 32 GB) и ввиду этого отстреливает всех пользователей с ошибкой:
[i]WARNING: terminating connection because of crash of another server process
The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
Детали, если важны:
1. Запрос выполняется успешно практически всегда без последствий, исключение до 10% - оно печальное, как описано выше.
2. Редакция PostgreSQL — свободная, версии 12.3
3. Платформа Windows 2008/2016
4. Данных в связке из представлений и таблиц в строках не так много, не если учитывать условия, то 300 000, 180 000, 3 000 000, и 50 строк, если с условиями – результат до 5000 строк
Вопрос - как лечить такую ошибку?
Спасибо,
P.S. в дополнительной информации о данных ограничены со стороны информационной безопасности.
l
там еще wal журнал же будет нужен емнип
VY
Вопрос тупой конечно, но как на счет выставления флага бекапа, копирования фс и снятия флага? Это будет быстро? Ведь восстановиться - просто раскатать tar ?
зачем изобретать велосипед? там столько нюансов всплывёт, которые другие уже поймали и поправили
MM
X Z
Коллеги, доброго времени.
Вероятно в этом чате есть гуру и эксперты,
которые помогут подсказать направление куда копать, в какую сторону,
заранее спасибо!
Получаем вот такую ошибку:
org.postgresql.util.PSQLException: ERROR: out of memory
Подробности: Failed on request of size 8 in memory context "Subplan HashTable Temp Context".
В одной из сессий происходит выполнение составного запроса типа select столбцы, а также подселекты с count(*) как виртуальные столбцы из связки представлений и таблиц с условиями,
в условиях есть сравнение значений в подселектами с count(*).
При этом Postgres ( этот процесс ) съедает всю память на сервере (до 32 GB) и ввиду этого отстреливает всех пользователей с ошибкой:
[i]WARNING: terminating connection because of crash of another server process
The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
Детали, если важны:
1. Запрос выполняется успешно практически всегда без последствий, исключение до 10% - оно печальное, как описано выше.
2. Редакция PostgreSQL — свободная, версии 12.3
3. Платформа Windows 2008/2016
4. Данных в связке из представлений и таблиц в строках не так много, не если учитывать условия, то 300 000, 180 000, 3 000 000, и 50 строк, если с условиями – результат до 5000 строк
Вопрос - как лечить такую ошибку?
Спасибо,
P.S. в дополнительной информации о данных ограничены со стороны информационной безопасности.
Вероятно в этом чате есть гуру и эксперты,
которые помогут подсказать направление куда копать, в какую сторону,
заранее спасибо!
Получаем вот такую ошибку:
org.postgresql.util.PSQLException: ERROR: out of memory
Подробности: Failed on request of size 8 in memory context "Subplan HashTable Temp Context".
В одной из сессий происходит выполнение составного запроса типа select столбцы, а также подселекты с count(*) как виртуальные столбцы из связки представлений и таблиц с условиями,
в условиях есть сравнение значений в подселектами с count(*).
При этом Postgres ( этот процесс ) съедает всю память на сервере (до 32 GB) и ввиду этого отстреливает всех пользователей с ошибкой:
[i]WARNING: terminating connection because of crash of another server process
The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
Детали, если важны:
1. Запрос выполняется успешно практически всегда без последствий, исключение до 10% - оно печальное, как описано выше.
2. Редакция PostgreSQL — свободная, версии 12.3
3. Платформа Windows 2008/2016
4. Данных в связке из представлений и таблиц в строках не так много, не если учитывать условия, то 300 000, 180 000, 3 000 000, и 50 строк, если с условиями – результат до 5000 строк
Вопрос - как лечить такую ошибку?
Спасибо,
P.S. в дополнительной информации о данных ограничены со стороны информационной безопасности.
Может дело в платформе?
MM
Указанное количество строк - это же так... немножно....
MM
Вопрос еще в корректности запроса... Или больше памяти на машину воткните