Хорошее how-to, с достаточно хорошо прокоментированными конфигами. Но имхо, недостаточно объяснений, например:
1) Почему используется именно такая конфигурации keepalived? Она избыточна и это неспроста, а вот почему не рассказано.
2) Почему удаляете хосты по умолчанию и приводите их к совершенно другому виду.
3) Это очень важный шаг: net.ipv4.ip_nonlocal_bind=1 — Почему?
поторопился с первым каментом, напишу более развернуто. я протестую против ALL в конце,
я бы сделал так «zabbix ALL=(root) NOPASSWD: /usr/bin/socat»
а то ваш вариант приравнивает аккаунт zabbix'а почти к руту.
вот тоже неплохой пример если уже есть определенная политика в отношении sudo для других пользователей
Около года используем FlashCache в продакшене под postgresql базами, отзывы только положительные. Отличия:
Flashcache основан на devoce-mapper поэтому перед тем как начать его использовать, нужно «слепить» гибридный dm-том из имеющегося тома и SSD-тома/раздела/диска. И потом это гибридное устройство монтировать и использовать.
Bcache (как и EnhanceIO) это отдельный блочный драйвер, не использующий device-mapper слой.
Оба отличаются подходом в создании томов (в flashcache мне как-то показалось проще это устроено, bcache показался непривычным flashcache… а enhanceio вобще показался сказкой, но он медленный это правда + пару раз ловил kernel panic).
>> на мастере в команде архивирования надо указывать путь к папке на реплике, чтобы мастер туда складывал wal-файлы на время активного pg_base_backup при первоначальной «наливке» реплики
Необязательно складывать архивы на реплику. Можно складывать локально, а потом на слейве указать restore_command = 'scp user@master:/path/to/archive/%f "%p"'. Пусть берет их по сети.
Наоборот старался сократить объем, в развернутом виде, как мне показалось, получилось слишком много текста и выглядит нудно (более подробно расписал пункты реализации).
скрипты да, требуют тщательного изучения т.к. при работе могут создать определенную нагрузку
c pg_basebackup получается так. Вы заходите на свой сервер который хотите сделать слейвом, создаете там каталог «dest_dir» в котором будет жить реплика и выполняете там pg_basebackup -P -v -h master_ip -U postgres -D dest_dir (не забываем про pg_hba.conf на мастере)
pg_basebackup выполнит подключение к указанному серверу по протоколу репликации, сделает чекпойинт черезpg_start_backup и начнет передавать данные в ваш каталог дест_дир, по завершению сделает pg_stop_backup. Вам остается сделать chown -R postgres: dest_dir, указать recovery.conf и запуститься. Постгрес прочитает recovery.conf и запустится в соответствии с ним (прочитает нужные wal-архивы и догонит мастера). Все слейв готов))
начиная с 9.2 стендбай тоже умеет отдавать.
With 9.2, a standby can also send replication changes, allowing cascading replication. wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.2#Replication_improvements
pg_ctl не может быть «не в комплекте», скорей всего он не прописан в PATH (наверное у вас RHEL/CentOS), поищите, найдется.
триггер файл открывает хот-стендбай для записи, а собственно чем отличает мастер от хот-стендбая? именно возможностью записи)) так что тут игра слов… После создания триггер файла вы получаете standalone постгрес сервер. И последующая настройка потоковой это уже отдельное дело.
При настройке потоковой репликации, всегда стоит помнить про триггерный файл. провозглашение хот-стендбая в мастер становится делом нескольких секунд.
Архивы WAL рекомендуется бэкапить на отдельный узел, чтобы в случае аппаратных проблем на мастере, хот-стендбай мог их подтянуть для себя.
Используйте pg_basebackup, он делает тоже самое что и pg_start/stop_backup + rsync, но в одной command line.
Более детальней посмотрите на раздел с описанием использования ресурсов, оф.справка PG всегдя является хорошей отправной точкой.
Почитать про оптимизацию постгреса можно в блогах, например у Depesz, у него достаточно часто появляется свежая инфа и есть статьи с фундаментальными вещами.
У постгреса или kvm?
Постгрес по умолчанию настроен на работу таким образом как будто он запущен на машине с памятью меньше 1GB (shared_buffers) на одном диске (effective_io_concurrency) и как-будто в него совсем не будет записи (checkpoint_segments). Пожалуй к этому можно добавить ident авторизацию (по умолчанию в RHEL/CentOS) которая вводит в прострацию новичков)))).
В KVM может использоваться дефолтное кэширование (writethrough) которое во некоторых случаях не идеально (гости на внешних хранилищах по iSCSI или NFS). Не используются hugepages, отключены некоторые вкусные процессорные флаги. Паравиртуальные драйвера для устройств опять же не всегда по умолчанию.
Дефолтные настройки postgresql вообще ни к черту.
Дефолтные параметры запуска KVM зачастую нацелена на универсальную возможность запуска виртуалки на любом железе (производительность же второстепенна).
Если не секрет, расскажите поподробнее про «самописец — кольцевой», а то на уме одни догадки и гипотезы. В частности интересует общая схема, взаимосвязь компонентов, версии софта, причины почему используется такая схема.
>> несколько разные понятия.
да разные понятия, но цель преследуется общая, снизить размер индексов (кстати на графике в процессе работы над таблицей, незаметно чтобы индексы росли в размерах… хз почему так, такто должны были)
Да, fill factor очень полезен, нужно только заранее спрогнозировать дополнительное место, т.к. таблица будет занимать больше места чем собственно данные. И это дествительно только для UPDATE'ов.
>> Во-первых, INSERT никоим образом не раздувает таблицу, а лишь добавляет туда данные, собственно, как и DELETE — он просто не освобождает.
я не писал что INSERT раздувает таблицу. Раздувание идет за счет сочетающихся INSERT и DELETE.
>> Во-вторых, обратите внимание на ваши индексы после фейковых
ой, это известная проблема,… не зря там есть функция перестроения индексов (вы что не читали список возможностей?)
>> В итоге надо последовательно и инкрементально апдейтить записи. лучше идя от физического конца.
об этом тоже написано, четвертый абзац: «Если обновлять таблицу с помощью т.н. fake updates, типа some_column = some_column с последней страницы» (да хватит уже читать по диагонали)
>> Сам я в экстренных случаях использую «перекладывалку»
Сами то почему pg_reorg не используете? потому что есть риски. А вот погуглите про pgcompactor, о нем вобще интернеты не знают.
Имхо вы немножко поторопились с ответом и вывали все на горячую голову не осмыслив написаного (сложилось впечатление что читали текст по диагонали). Середина и конец коментария уже более вменяемея и есть конструктив относительно PG 8. (Про него я вообще ничего не могу сказать, т.к. не работал с ним).
Насколько мне известнт pg_reorg работает через создание новой таблицы и навешивание триггеров на старую и затем переносит данные из старой таблицы в новую (раньше было так, а сейчас может принцип работы тулзы и изменился).
Если интересно, еще есть compact_table от depesz.
Имею ввиду в вашей компании.
1) Почему используется именно такая конфигурации keepalived? Она избыточна и это неспроста, а вот почему не рассказано.
2) Почему удаляете хосты по умолчанию и приводите их к совершенно другому виду.
3) Это очень важный шаг: net.ipv4.ip_nonlocal_bind=1 — Почему?
я бы сделал так «zabbix ALL=(root) NOPASSWD: /usr/bin/socat»
а то ваш вариант приравнивает аккаунт zabbix'а почти к руту.
вот тоже неплохой пример если уже есть определенная политика в отношении sudo для других пользователей
Cmnd_Alias ZABBIX = /bin/cmd1, /sbin/cmd2, /usr/sbin/cmd3
zabbix ALL=(root) NOPASSWD: ZABBIX
это еще что за жесть?
Flashcache основан на devoce-mapper поэтому перед тем как начать его использовать, нужно «слепить» гибридный dm-том из имеющегося тома и SSD-тома/раздела/диска. И потом это гибридное устройство монтировать и использовать.
Bcache (как и EnhanceIO) это отдельный блочный драйвер, не использующий device-mapper слой.
Оба отличаются подходом в создании томов (в flashcache мне как-то показалось проще это устроено, bcache показался непривычным flashcache… а enhanceio вобще показался сказкой, но он медленный это правда + пару раз ловил kernel panic).
да, можно дергать DBA «эй, сделай-ка нам дамп», но я за автоматизацию)))
Необязательно складывать архивы на реплику. Можно складывать локально, а потом на слейве указать restore_command = 'scp user@master:/path/to/archive/%f "%p"'. Пусть берет их по сети.
скрипты да, требуют тщательного изучения т.к. при работе могут создать определенную нагрузку
pg_basebackup выполнит подключение к указанному серверу по протоколу репликации, сделает чекпойинт черезpg_start_backup и начнет передавать данные в ваш каталог дест_дир, по завершению сделает pg_stop_backup. Вам остается сделать chown -R postgres: dest_dir, указать recovery.conf и запуститься. Постгрес прочитает recovery.conf и запустится в соответствии с ним (прочитает нужные wal-архивы и догонит мастера). Все слейв готов))
With 9.2, a standby can also send replication changes, allowing cascading replication.
wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.2#Replication_improvements
триггер файл открывает хот-стендбай для записи, а собственно чем отличает мастер от хот-стендбая? именно возможностью записи)) так что тут игра слов… После создания триггер файла вы получаете standalone постгрес сервер. И последующая настройка потоковой это уже отдельное дело.
Архивы WAL рекомендуется бэкапить на отдельный узел, чтобы в случае аппаратных проблем на мастере, хот-стендбай мог их подтянуть для себя.
Используйте pg_basebackup, он делает тоже самое что и pg_start/stop_backup + rsync, но в одной command line.
Почитать про оптимизацию постгреса можно в блогах, например у Depesz, у него достаточно часто появляется свежая инфа и есть статьи с фундаментальными вещами.
Постгрес по умолчанию настроен на работу таким образом как будто он запущен на машине с памятью меньше 1GB (shared_buffers) на одном диске (effective_io_concurrency) и как-будто в него совсем не будет записи (checkpoint_segments). Пожалуй к этому можно добавить ident авторизацию (по умолчанию в RHEL/CentOS) которая вводит в прострацию новичков)))).
В KVM может использоваться дефолтное кэширование (writethrough) которое во некоторых случаях не идеально (гости на внешних хранилищах по iSCSI или NFS). Не используются hugepages, отключены некоторые вкусные процессорные флаги. Паравиртуальные драйвера для устройств опять же не всегда по умолчанию.
Дефолтные параметры запуска KVM зачастую нацелена на универсальную возможность запуска виртуалки на любом железе (производительность же второстепенна).
>> несколько разные понятия.
да разные понятия, но цель преследуется общая, снизить размер индексов (кстати на графике в процессе работы над таблицей, незаметно чтобы индексы росли в размерах… хз почему так, такто должны были)
я не писал что INSERT раздувает таблицу. Раздувание идет за счет сочетающихся INSERT и DELETE.
>> Во-вторых, обратите внимание на ваши индексы после фейковых
ой, это известная проблема,… не зря там есть функция перестроения индексов (вы что не читали список возможностей?)
>> В итоге надо последовательно и инкрементально апдейтить записи. лучше идя от физического конца.
об этом тоже написано, четвертый абзац: «Если обновлять таблицу с помощью т.н. fake updates, типа some_column = some_column с последней страницы» (да хватит уже читать по диагонали)
>> Сам я в экстренных случаях использую «перекладывалку»
Сами то почему pg_reorg не используете? потому что есть риски. А вот погуглите про pgcompactor, о нем вобще интернеты не знают.
Имхо вы немножко поторопились с ответом и вывали все на горячую голову не осмыслив написаного (сложилось впечатление что читали текст по диагонали). Середина и конец коментария уже более вменяемея и есть конструктив относительно PG 8. (Про него я вообще ничего не могу сказать, т.к. не работал с ним).
Если интересно, еще есть compact_table от depesz.