Вопросы Теги

Нечетные записи в журнале при запуске PotgreSQL

Определенный внешний дисковый массив, с которым я работал в прошлом, сделал невероятное (или таким образом, я думал), и отключил кэш на контроллере во время, восстанавливают операции. Если бы это смогло откачать 40-60MB/s обычно, то Вы могли бы получить насыщенность ввода-вывода записями всего 4MB/s в зависимости от того, в чем я установил приоритеты. Это было с 500 ГБ 7.2K об/мин диски SATA, также. Для решения с аппаратными средствами RAID и рекламируемый как являющийся устройством волоконно-оптического канала мультидоступа, это, конечно, не имело успеха на его поверхности при восстановлении с отказов.

Мы закончили тем в основном, что игнорировали это устройство. Это в настоящее время делает сервис как специализированное резервное копирование на дисковый массив для одного сервера резервного копирования. Я переформатировал его с RAID10 для большого упрощения, сколько времени это берет для восстановления с дефектных дисков. Что-то, что может перейти к тому низкому уровню записи ввод-вывод просто, не могло использоваться в производстве.

Который является длинным путем сказать, Ваш опыт отлично соответствует действительности.

0
задан 23 May 2017 в 15:41
3 ответа

Каков Ваш вопрос?

Ваш сервер запускает превосходный - "система баз данных, готово принять соединения"

Как только это становится готовым, существует много попыток соединить использование учетной записи "пост-ГРЭС" с неверным паролем, которые, кажется, прибывают из локального сервера.

Если Вы спрашиваете об этих записях, и они не Вы, похоже, что кто-то делает атаку с подбором по словарю на PostgreSQL. Странная вещь, похоже, что соединения прибывают из локального хоста, таким образом, они могли имитировать свой исходный адрес.

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

При поиске ответа на что-либо еще необходимо будет быть немного более конкретными.

1
ответ дан 4 December 2019 в 15:19
  • 1
    That' s вещь, все локально только. И всегда то же количество плохих попыток. 5432 не открыто в маршрутизаторе, и в сети нет определенно никаких неавторизованных пользователей. Я предположил, что программное обеспечение пыталось соединиться. –  Alex S 11 February 2010 в 00:38
  • 2
    Ваша проблема isn' t связанный с сервером пост-ГРЭС - некоторый другой (возможно жулик) процессы включены здесь, и если Вы разыщете их и заставите их вести себя уйдут, то Ваши таинственные сообщения журнала. Если you' ре не просто использование pg_ctl Вы посмотрели на сценарий запуска? Это было бы моим первым подозреваемым... –  voretaq7 11 February 2010 в 01:55
  • 3
    Просто примечание: брандмауэр won' t помогают Вам. [локальный] означает, что соединение вошло по локальному сокету домена Unix, не по localhost интерфейсу IP. –  Magnus Hagander 11 February 2010 в 11:00
  • 4
    Положительная сторона А-ч Magnus, я никогда не отмечал время прихода на работу к этому. В этом случае it' s почти наверняка что-то на Вашей машине в противоположность сети. Существует, конечно, что-то жулик здесь из-за " недопустимый запуск packet" сообщения, но только на нескольких попытках. Это могло быть что-то столь же простое как сетевая система контроля (у Вас есть тот?) проверка сервера жива (хотя несколько раз секунда является чрезвычайно персистентной), или это могло быть что-то, что жулик как @voretaq7 сказал. Исследуйте свой главный вывод и посмотрите если there' s что-либо Вы don' t распознают там. –  Andy Shellam 11 February 2010 в 21:22

Это очень похоже на комбинацию двух вещей:

-Ваш pg_hba.conf не разрешает локальному пользователю "postgres" -Ваш сценарий rc.d пытается получить статус базы данных, установив соединение с локальной базой данных в качестве пользователя «postgres» для подтверждения запуска

. Я бы посоветовал проверить сценарий rc. Если вы видите, что именно это и происходит, либо измените сценарий, указав пароль, либо измените pg_hba.conf, чтобы доверять этому пользователю. Перезагрузите компьютер и посмотрите, исчезнут ли ошибки ...

1
ответ дан 4 December 2019 в 15:19

Someone also answered this over at stackoverflow: https://stackoverflow.com/questions/7038342/password-authentication-failed-for-user-postgres

The first answer, from Berry Langerak, solved this problem for me.

0
ответ дан 4 December 2019 в 15:19

Теги

Похожие вопросы