Etherpad-lite: Изящно обрабатывать недоступность подключения к базе данных

Созданный на 12 нояб. 2020  ·  5Комментарии  ·  Источник: ether/etherpad-lite

Опишите ошибку
Когда соединение базы данных с внутренним хранилищем недоступно (проверено с помощью postgres), сервер продолжает давать сбой, вместо того, чтобы корректно сообщать о проблемах с подключением к базе данных.

Воспроизводить
Шаги по воспроизведению поведения:

  1. Остановите сервер базы данных (postgres)
  2. Запустить etherpad
  3. Посетите какую-либо страницу, которая требует подключения к базе данных (в моем случае должна работать любая панель, которая также запускается при просмотре /admin/plugins
  4. Увидеть ошибку

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

Фактическое поведение

[2020-11-12 22:13:05.858] [ERROR] console - error: column "value" is of type jsonb but expression is of type text
    at Parser.parseErrorMessage (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:278:15)
    at Parser.handlePacket (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:126:29)
    at Parser.parse (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:39:38)
    at Socket.stream.on (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/index.js:8:42)
    at Socket.emit (events.js:198:13)
    at Socket.EventEmitter.emit (domain.js:448:20)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)
    at Socket.Readable.push (_stream_readable.js:224:10)
    at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
[2020-11-12 22:13:05.858] [INFO] console - Stopping Etherpad...
[2020-11-12 22:13:05.876] [ERROR] console - TypeError: Cannot read property 'name' of null
    at Client._handleParseComplete (/home/etherpad/etherpad-lite/src/node_modules/pg/lib/client.js:358:26)
    at Connection.emit (events.js:198:13)
    at Connection.EventEmitter.emit (domain.js:448:20)
    at parse (/home/etherpad/etherpad-lite/src/node_modules/pg/lib/connection.js:109:12)
    at Parser.parse (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:40:17)
    at Socket.stream.on (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/index.js:8:42)
    at Socket.emit (events.js:198:13)
    at Socket.EventEmitter.emit (domain.js:448:20)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)

Дополнительный контекст

Etherpad version
Version number: 1.8.6
Latest available version: 1.8.6
Git sha: 6a8563e
picture BenBE

Самый полезный комментарий

О, проверьте возвращенные коммиты. Некоторое время назад был плохой коммит pg, связанный, я думаю ...

picture JohnMcLear 12 нояб. 2020
👍2

Все 5 Комментарий

+1 это.

https://github.com/ether/ueberDB для нашей абстракции базы данных, кстати. Это не просто проблема с PG, затрагивает все БД.

Я бы согласился с PR, я не уверен, где лучше всего это исправить, я думаю, что ueberdb испускает, когда db теряется.

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

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

JohnMcLear picture JohnMcLear 12 нояб. 2020
👍1

Я не думаю, что это проблема с подключением. column <name> is of type jsonb but expression is of type text кажется довольно обычным явлением, которое происходит, когда промежуточное программное обеспечение устанавливает параметры запроса неожиданным образом. Столбец создается как JSONB, но когда генератор запросов использует что-то вроде JSON.encode, тип определяется как строка, а параметр привязан как тип TEXT или VARCHAR («символ меняется» в сообщениях об ошибках).
По-видимому, это также может быть проблемой при хранении строк или массивов вместо содержащих их объектов?

Случайный пример, найденный через Google, не связанный с этим проектом: https://github.com/jeremydaly/data-api-client/issues/27#issuecomment -584701957

martok picture martok 12 нояб. 2020
👍1

О, проверьте возвращенные коммиты. Некоторое время назад был плохой коммит pg, связанный, я думаю ...

JohnMcLear picture JohnMcLear 12 нояб. 2020
👍2

Я только что заметил - похоже, у нас есть CREATE TABLE с jsonb в нем, версия в node_modules уже просто text . FWIW у нас также есть ueberdb_insert_or_update() с текстовым аргументом, ни одного перегруженного не осталось ...

Просто чтобы убедиться, прежде чем я его конвертирую, текст такой, каким он должен быть (на данный момент)?

martok picture martok 13 нояб. 2020
👍1

После преобразования в текст вроде все работает:

ALTER TABLE storage ALTER COLUMN value TYPE text USING value::text;
BenBE picture BenBE 13 нояб. 2020
👍1
Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

zeer15398376 picture zeer15398376  ·  9Комментарии
kernelfreak picture kernelfreak  ·  9Комментарии
YSelfTool picture YSelfTool  ·  5Комментарии
julpec picture julpec  ·  9Комментарии
aswen picture aswen  ·  7Комментарии