Восстановление очереди хроники после жесткого сбоя питания

все, что находится в кеше грязных страниц ядра Linux, теряется.

Да

Каков наилучший подход к гарантированному восстановлению в случае сбоя питания?

Реплицируйте данные на второй или третий компьютер. Таким образом, даже если всю машину/центр обработки данных невозможно восстановить, вы сможете продолжить работу без потери данных.

Будет ли хорошим подходом массив RAID с резервным питанием от батареи вместе с принудительной очисткой при записи?

Вы должны доверять надежности оборудования, что Chronicle не может гарантировать, и многие из наших клиентов уже обожглись.

Или лучше использовать репликацию с акком со второй машины, прежде чем считать, что запись благополучно записана?

Это зависит от ваших требований. По нашему мнению, это наилучшая практика, хотя многие клиенты считают, что эта опция им не нужна.

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

Какой из этих подходов будет иметь наилучшую производительность?

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

Примечание: есть несколько альтернатив.

• Вы можете ждать подтверждения только для критических сообщений, другие типы сообщений могут быть обработаны немедленно.
• Вы можете разрешить окно, в котором вы обрабатываете сообщения, если не было подтверждено не более N.

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

Вот где репликация 2+1 может быть вариантом. Рядом один резервный сервер для восстановления нормальной работы в случае выхода из строя стойки или ее части. Вторая резервная копия за пределами сайта, которая медленнее реплицируется, но имеет меньше шансов на сбой.