Не получается с заменой в preg_replace()?

А не json ли там случаем? К чему извращения с регулярками?

Pgpool2 multy-master mode где искать мануалы по настройке? Как вы масштабируете базу(под запись)?

Поделитесь пожалуйста советом как вы "распиливаете" базу штатной потоковой репликацией

Никак. Кластера полностью независимые между собой.

Приложение само решает, в какой кластер ему идти и так же само решает на какой тип машины идти: мастер, online реплика или slow реплика для возможно длительных запросов
Мастер никаким роутингом не занимается.

Как скинуть проверку жесткого диска на убунту?

anton_myaso, куда-куда. В логи, конечно.

Как скинуть проверку жесткого диска на убунту?

clean значит clean. Это не ошибка и ищете вы не там.

Postgresql+потоковый бекап: как победить проблему с правами на папку?

покажите ls -l /var/lib/postgresql/9.6/ с мастера и реплики. В нормальном виде должно быть (дата только своя):

drwx------ 19 postgres postgres 4096 ноя 14 11:28 main

Postgresql как ограничить общий размер WAL-файлов?

Тогда не трогайте настройки мастера кроме как max_wal_senders (если был выключен) (для basebackup необходимо минимум 2 коннекта). Ну и чуть-чуть wal_keep_segments всё-таки можно поднять.
По-умолчанию мастер не будет дожидаться реплику. Если мастеру хочется удалить wal - он их удалит как ни в чём не бывало. Если реплика этот wal не прочитала ещё - то получит потом отлуп и надо будет pg_basebackup делать заново. (для изменения этого поведения как раз replication slots и появились)

pg_basebackup -X stream открывает два соединения: по одному копирует базу, по второму подписывается на все новые wal как рядовая реплика. Поэтому во время его работы мастер работает как ни в чём не бывало и удаляет wal как обычно. А вот на реплике wal будут копиться. И стартовать реплика может немного не сразу, пока все эти wal проигрывает. Неприятный момент - за новыми wal к мастеру реплика пойдёт только когда разгребёт все локально записанные wal.

В общем, делается в screen pg_basebackup с ключом --progress, когда он доработал - открывается в другой консоли tail -f лога будущей реплики, запускается реплика и ждём ready to accept connections и starting streaming. Если посыпались ошибки wal segment already removed - стопаем реплику, на мастере поднимаем keep segments и пробуем налить реплику ещё раз. (у нас в dataegret обычно изначально keep segments задран)

Как избежать блокировки параллельных запросов в Postgresql?

21 секунду работали, 508 секунд ждали диски. Естественно если сюда добавлять ещё конкурентной нагрузки - будет только хуже.
explain видите? Глядя на него мысли повесить индекс-другой не возникает? Нет? А почему?

Как избежать блокировки параллельных запросов в Postgresql?

Моя рабочая гипотеза - у вас медленные механические диски и достаточно данных чтобы не помещаться в памяти. В таких условиях один запрос работающий 2 минуты в 10 потоков выполняться час может вполне. Потому что random io на механике - это всегда больно.

Поскольку вы отказываетесь ответить на мои вопросы - ничем больше помочь не могу. Если моя гипотеза верна - в один поток последовательно будет быстрее работать.

sql знаю на уровне запросов, по мне так больше знать и не нужно

explain это уровень именно запроса. И его вы как разработчик понимать должны. Потому что непосредственно работаете с базой. Тем более поскольку ДБА у вас в команде нет, который будет по рукам бить за совершение глупостей.

Как избежать блокировки параллельных запросов в Postgresql?

yuharu, как postgresql DBA поясняю: shared_buffers - это такая настройка postgresql. Чтобы не гадать, где та переопределяется и с чем база запущена - лучше про неё спросить саму запущенную базу запросом show shared_buffers. Explain - это explain. Как (судя по вопросу) разработчик работающий с СУБД вы должны знать что это. Дополнительные параметры за explain - это дополнительные параметры explain. Лучше бы разработчики о них тоже знали, ну да ладно. Это то, по чему можно много полезного и увлекательного узнать о проблемных запросах. track_io_timing - настройка, добавляющая ещё полезных данных в секцию buffers у explain. А больше ничего про базу я ещё не спросил, всё остальное обычные системные метрики которые надо узнать у сисадмина.

Если не хотите разбираться в работе базы - вам дорога во фриланс или, например, к нам в dataegret за коммерческой поддержкой (ссылка у меня в профиле есть).

Как избежать блокировки параллельных запросов в Postgresql?

ну и explain (analyze,buffers) запроса при включенных track_io_timing может интересную информацию показать.

Как избежать блокировки параллельных запросов в Postgresql?

buffer_io Waiting for I/O on a data page.

https://www.postgresql.org/docs/9.6/static/monitor...

Какие диски? Добавьте в вопрос графики мониторинга с io util и iops. Или штук 5-10 листингов iostat -x 1 при выполняемых запросах.
Плюс сколько памяти всего (free -h) и сколько выделено shared_buffers

Не могу понять что не так? json_decode почему не работает?

mrWan, и чем же это вам упростило поиск ошибки? Вы это написали и вы этим не смогли воспользоваться никак. Вы даже не посмотрели, что вам возвращает функция, иначе ваш вопрос звучал бы совсем иначе.
В рабочем режиме тем более. Функция, выдающая в зависимости от фазы луны строку с результирующими данными или строку с описанием ошибки - это к проблемам.

Тяжелые команды для БД с большим количеством записей?

longclaps, именно только для myisam. Для мультиверсионного транзакционника innodb вопрос "сколько у тебя строк" не имеет смысла вообще. Имеет смысл "сколько версий строк видит моя транзакция". И без проверки каждой строки на видимость в конкретной транзакции это не узнать. В статистике же хранится приблизительное число строк.

Проблема с блоком питания, как решить???

TrueNinja, а кто сказал, что в блоке питания нет проблемы? Симптоматика не характерная и только, а причиной быть по-прежнему может.
Температуры в норме - это в числах сколько? Раздельно по каждому ядру CPU, GPU и VRM

Е5-2640v4 6 ядер ощутимо мощнее, чем Е5-1650v3 6 ядер или нет?

SyavaSyava,

Думаю в этом контексте максимальным ограничением поддерживаемой памяти можно пренебречь

Это если не стоит выбор между двумя конкретными конфигурациями: с 32гб или 64 гб. В вопросе именно так описано, поэтому я не про максимальных поддерживаемый объём.

Е5-2640v4 6 ядер ощутимо мощнее, чем Е5-1650v3 6 ядер или нет?

Базе нужна преимущественно память (но и ядра тоже), веб-серверу - в зависимости от качества написанного кода. Но параллелится нагрузка этого профиля хорошо.
Проглядел в тегах - похоже речь о VPS. Выясните у хостера - выделяются статично ядра физические или как повезёт и можно получить псевдоядра HT? И раз это VPS - то сколько в итоге дают вам ядер?

MYSQL не заполняется auto_increment, что делать?

primary key в принципе не может быть null. auto_increment не может быть отдельно от первичного или уникального ключа. Подцепитесь штатным консольным клиентом и проверьте данные и show create table в консоли.

Как хранить базу postgres 8.4 в памяти?

synchronous_commit в 8.4 уже был https://www.postgresql.org/docs/8.4/static/runtime...
Но перед выключением внимательно прочитайте что именно эта гайка делает. tradeoff между производительностью и риском потери последних коммитов при аварии.

Как хранить базу postgres 8.4 в памяти?

huge pages - это к параметрам операционной системы. До 9.2 включительно можно было извращаться с libhugetlbfs. А вот начиная с какой версии можно было извращаться - хз. Впрочем до 32гб памяти можно не заморачиваться.

shared_buffers 32мб - это кошмар. Годится только если вы на каком-нибудь утюге запустились где всего 128-256мб памяти.
Чтобы понимать масштабы - postgresql будет обрабатывать данные только в shared_buffers. Чтобы сходить за данными в индекс - надо прочитать какие-то части индекса в shared_buffers (минимум 1 страничку корня btree, дальше как получится по запросу). Чтобы по полученным из индекса ctid сходить за данными - надо идти в таблицу, читать страницы в shared_buffers. И постоянно вытеснять другие страницы из shared_buffers. Потому что в 32мб можно поместить всего 32мб/8кб = 4096 страниц. Картину немного исправляет то, что postgresql использует системный файловый кеш. Но ходить настолько интенсивно в файловый кеш штука не бесплатная.

Наша в dataegret обычная рекомендация - отдельная машина только под базу, 25% RAM под shared_buffers. Т.е. никаких приложений на той же машине - иначе невозможно контролировать ресурсы. Какой-нибудь PHP случайно откушал на 20гб памяти и база в свопе - это из реальной практики. Если база влезает в память - то можно до 75% памяти отдать под shared_buffers.

Индексы - если кратко то всё сложнее. Ненужными индексами можно сделать хуже (особенно в зависимости от интенсивности записи). Писать ещё одно сочинение по тому как проставлять индексы настроения нет. Есть замечательный материал здесь: use-the-index-luke.com

Как хранить базу postgres 8.4 в памяти?

Надо учитывать, что гайки и fsync и synchronous_commit - это для операций записи. Если много читаем с медленных дисков - они никак не повлияют на происходящее.