Назад | Перейти на главную страницу

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

Мои требования:

1) должен иметь возможность продолжать работу после сбоя узла 2) журналы должны восстанавливаться после сбоя узла - без потери данных 3) должно иметь возможность масштабирования 4) должно быть транзакционным - когда сообщение регистрируется, мне нужна гарантия, что оно сохраняется на диске

Это похоже на предыдущий мой вопрос, но я только что осознал важность транзакционной функции. Это для медицинского приложения; мы не можем позволить себе потерять сообщения журнала.

Спасибо!!

Из того, что вы описали выше, вам нужны непрерывные вычисления. Существует два типа программного обеспечения на платформе Windows, которое может предоставить то, что вы ищете. Я не слишком знаком с какими-либо приложениями для ведения журнала транзакций. С обоими нижеприведенными решениями HA / FT вы можете просто использовать практически любые. (пока они работают в windows)

  1. Neverfail

Neverfail - это решение высокой доступности, которое защищает ваше приложение от потери данных. В случае сбоя сервера переключение между обоими серверами не кажется очевидным (не требует вмешательства человека), и в зависимости от того, сколько данных все еще остается в памяти, которые не записываются для ввода-вывода на активном сервере, пассивный сервер возьмет на себя операции. Это обеспечит вам время безотказной работы почти 99,99%.

  1. Марафон

Marathon похож на Neverfail, но имеет дополнительную защиту - защиту компонентов. Благодаря их функции FT, если на вашем сервере случится какой-либо сбой, например, сбой диска или даже сбой сети, ваше приложение продолжит работу. Таким образом, нет потери данных или прерывания работы.

Надежная пересылка с помощью rsyslog поможет вам начать. В документы rsyslog также есть страницы, описывающие, как записывать данные в базу данных и как масштабировать запись в базу данных.

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

ЕСЛИ у вас уже была система БД с соответствующей настройкой аварийного переключения и высокой доступности, вы могли бы настроить два сервера журналов и использовать систему периодического контроля (возможно, linux-ha) для автоматического получения IP-адреса от сервера регистрации в реальном времени.