Записки архитектора

Многие думают, что изменение параметров в postgresql.conf — это реальный путь к успеху. Однако это не всегда так. Конечно, чаще всего хорошие параметры конфигурации базы данных очень полезны. Тем не менее, во многих случаях реальные проблемы будут возникать из-за странного запроса, скрытого глубоко в некоторой логике приложения. Даже вполне вероятно, что запросы, вызывающие реальные проблемы, не являются теми, на которые вы обратили внимание. Возникает естественный вопрос: как мы можем отследить эти запросы и выяснить, что на самом деле происходит? Мой любимый инструмент для этого — pg_stat_statements, который всегда должен быть включен по моему мнению, если вы используете PostgreSQL 9.2 или выше (пожалуйста, не используйте его в более старых версиях).
 

Скачиваем с данного сайта последние версии приложений:

 https://sourceforge.net/projects/pentaho/files/ 

• pentaho-server-ce-9.0.0.0-423.zip — сервер для запуска отчетов
• prd-ce-9.0.0.0-423.zip — дизайнер отчетов

Для реализации потоковой репликации требуется наличие, как минимума 2-х серверов:

• Имя мастера: master-db / IP 192.168.0.1
• Имя слейва: slave-db / IP 192.168.0.2

Устанавливаем на каждый сервер postgresql:

sudo apt-get update 
sudo apt-get install postgresql postgresql-contrib 

Устанавливаем дополнения:

sudo apt-get install postgis  sudo apt install postgresql-10-postgis-scripts sudo apt install postgresql-plv8 sudo apt install nodejs npm 

Настраиваем мастер

Создаем пользователя для репликации:

sudo su postgres #В этот момент мы авторизовываемся под пользователем postgres 
psql 
postgres=# CREATE USER replica REPLICATION LOGIN CONNECTION LIMIT 2 PASSWORD 'qwe-123'; 
\q