Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
 Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
Сервер: Linux 3.14.14-gentoo_amd64
Firebird: 3.0.5.33220 Classsic.
Размер базы: 220Gb
Количество одновременных коннектов: ~600 шт

Началось все с того, что на сервере убили ~30 процессов firebird. Не спрашивайте зачем. Нужды в этом особой не было, но так уж случилось. После этого начались проблемы:
1. К базе стало невозможно подключиться.
2. В течении 10 минут количество процессов firebird выросло до 1,5 тыс.
3. gfix -shut single -force 0 - зависает.

С помощью утилиты fb_lock_print -a -d снял дамп менеджера очередей, нашел блокировку:
fb_lock_print
LOCK BLOCK 64870616
Series: 3, State: 6, Size: 8, Length: 8, Data: 0
Key: 0001:000000, Flags: 0x00, Pending request count: 1065
Hash que (14): forward: 38456480, backward: 2652656
Requests (1066): forward: 63629224, backward: 36366616
Request 63629224, Owner: 43476928, State: 6 (6), Flags: 0x20

OWNER BLOCK 43476928
Owner id: 83949430767623, Type: 1
Process id: 19546 (Alive), Thread id: 19547
Flags: 0x02 wake
Requests (2545): forward: 29851168, backward: 63629224
Blocks: *empty*
Pending: *empty*


Потом нашел этот процесс [Owner: 43476928] и убил его. Надеялся, что это поможет, но не оправдалось. fb_lock_print, стал сообщать, что хоть процесс и мертв, но ресурс, все равно, остается им заблокирован:
fb_lock_print
LOCK BLOCK 64870616
Series: 3, State: 6, Size: 8, Length: 8, Data: 0
Key: 0001:000000, Flags: 0x00, Pending request count: 1065
Hash que (14): forward: 38456480, backward: 2652656
Requests (1066): forward: 63629224, backward: 36366616
Request 63629224, Owner: 43476928, State: 6 (6), Flags: 0x20

OWNER BLOCK 43476928
Owner id: 83949430767623, Type: 1
Process id: 19546 (Dead), Thread id: 19547
Flags: 0x02 wake
Requests (2545): forward: 29851168, backward: 63629224


Надежды на корректный shutdown не осталось. Поэтому прибили все процессы firebird и стали лечиться:
1. Выполнили gfix -mend -ig <database>. В firebird.log показало кучу варинингов и несколько ошибок:
Error: Data page 12975396 {sequence 868380} marked as secondary but contains primary record versions in table T_ACC_BALANCES (128)
Error: Index 1 is corrupt {missing entries for record 656196} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 3 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 4 is corrupt {missing entries for record 1005346} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 5 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 7 is corrupt {missing entries for record 1217902} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 8 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 9 is corrupt {missing entries for record 1217902} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 10 is corrupt {missing entries for record 1262171} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 11 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 12 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 14 is corrupt {missing entries for record 1005346} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 15 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 18 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 19 is corrupt {missing entries for record 1217902} in table T_CR_CLIENTS_PARAM (1133)
Validation finished: 15 errors, 336 warnings, 281 fixed

2. Пересоздали индексы на таблицу T_CR_CLIENTS_PARAM (Alter index inactive + active).
3. После этого выполнили gfix -v -full <database>. Ошибок не стало. Запустились. Простой составил ~1:20.
29 июн 20, 19:56    [22159246]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28878
bsv9
(Alter index inactive + active).

на заметку - inactive не нужно, достаточно active. Тем более что inactive не сработает для индексов PK, FK, UNIQUE. А просто active - сразу перестроит индекс.
29 июн 20, 21:17    [22159259]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
hvlad
Member

Откуда:
Сообщений: 10954
bsv9
1. К базе стало невозможно подключиться.
Нужно было снять полный дамп памяти с процесса, который не может подключиться. И fb_lock_print -c -a

Подключение пробовали сетевые или локальные (embedded) ?

bsv9
2. В течении 10 минут количество процессов firebird выросло до 1,5 тыс.
Где-то "умный" пул коннектов подсобил ?

bsv9
3. gfix -shut single -force 0 - зависает.
Не зависает, а долго работает. Там же 1500 процессов, это не быстро.
Обычно делают full а не single, потом можно в single перевести, если нужно монопольно что-то делать.

bsv9
С помощью утилиты fb_lock_print -a -d снял дамп менеджера очередей, нашел блокировку:...Потом нашел этот процесс [Owner: 43476928] и убил его.
Я даже не буду спрашивать зачем, кто научил и какого чёрта это было сделано.
Для себя вывод - не надо слишком много рассказывать о внутренностях. Может даже вообще ничего не надо рассказывать. Ибо чревато...

bsv9
fb_lock_print, стал сообщать, что хоть процесс и мертв, но ресурс, все равно, остается им заблокирован:
А сколько ждали ? Или в панике лупили на все кнопки подряд ?


В итоге - легко отделались, считай вообще без последствий, кроме простоя.
29 июн 20, 23:09    [22159307]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
hvlad
Нужно было снять полный дамп памяти с процесса, который не может подключиться. И fb_lock_print -c -a

В следующий раз сделаем.

hvlad
Подключение пробовали сетевые или локальные (embedded) ?

Только сетевые. embeded - не пробовали.

hvlad
bsv9
2. В течении 10 минут количество процессов firebird выросло до 1,5 тыс.
Где-то "умный" пул коннектов подсобил ?

Да, java и php со своими пулами.

hvlad
bsv9
3. gfix -shut single -force 0 - зависает.
Не зависает, а долго работает. Там же 1500 процессов, это не быстро.

Ждали завершения [gfix -shutdown], примерно, 20 минут. После этого решили попробовать убить блокирующий процесс.

hvlad
bsv9
fb_lock_print, стал сообщать, что хоть процесс и мертв, но ресурс, все равно, остается им заблокирован:
А сколько ждали ? Или в панике лупили на все кнопки подряд ?

Примерно, 10 минут ждали. Мало?
30 июн 20, 07:18    [22159392]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
bsv9
Началось все с того, что на сервере убили ~30 процессов firebird.

Ошибся. На самом деле, убили всего 4 процесса.
30 июн 20, 07:27    [22159395]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1891
bsv9
... и php со своими пулами.

нет там никакого пула
30 июн 20, 07:44    [22159401]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
hvlad
Member

Откуда:
Сообщений: 10954
bsv9
hvlad
Подключение пробовали сетевые или локальные (embedded) ?

Только сетевые. embeded - не пробовали.
Тогда достаточно было бы остановить процесс слушателя и новые коннекты перестали бы добивать сервер.

bsv9
hvlad
А сколько ждали ? Или в панике лупили на все кнопки подряд ?

Примерно, 10 минут ждали. Мало?
Получается - мало. Хотя и несколько странно, но я не знаю полной картины
30 июн 20, 08:55    [22159433]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
Еще всплыла подробность, может она кому нибудь поможет. Оказывается админ убил не обычные 4 процесса firebird, а это были зомби.
30 июн 20, 13:14    [22159630]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 31192

30.06.2020 13:14, bsv9 пишет:
> Оказывается админ убил не обычные 4 процесса firebird, а это были зомби.

это он так говорит

Posted via ActualForum NNTP Server 1.5

30 июн 20, 13:28    [22159642]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
Мимопроходящий
30.06.2020 13:14, bsv9 пишет:
> Оказывается админ убил не обычные 4 процесса firebird, а это были зомби.
это он так говорит


Это были не зомби-процессы в классическом понимании linux, а процессы без коннектов. Увидели их так:
админ
выполнил: ps aux | grep апр
Показал апрельские процессы.
потом выполнил:
lsof -p PID
и там у процесса firebird не было TCP, а была такая запись:
firebird 19546 firebird 0u sock 0,6 0t0 3138087777 can't identify protocol

Сразу после их убийства произошел крэш.

Вот здесь http://tracker.firebirdsql.org/browse/CORE-6269 была исправлена проблема с зомби-коннектами в линуксе. Попробуем обновиться.

Однако, разве, может убийство 4 процессов привести к таким фатальным последствиям? Очевидно, проблема в чем то другом.
сегодня, 07:48    [22160536]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
alekcvp
Member

Откуда:
Сообщений: 2177
bsv9
Однако, разве, может убийство 4 процессов привести к таким фатальным последствиям? Очевидно, проблема в чем то другом.

Если это были maintance процессы, которые выполняли какие-то задачи в момент убийства, то ещё как может.
сегодня, 09:08    [22160559]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
alekcvp

Если это были maintance процессы, которые выполняли какие-то задачи в момент убийства, то ещё как может.


Как нибудь можно отличить maintance процессы от обычных?
сегодня, 09:11    [22160563]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
hvlad
Member

Откуда:
Сообщений: 10954
bsv9
Однако, разве, может убийство 4 процессов привести к таким фатальным последствиям?
Где фатальные последствия ? Потерялась хоть одна запись в БД ?
Я понимаю, что для админа (особенно для ответственного) подобные ситуации - стресс.
Но уже прошло время, уже можно трезво оценить последствия и перестать паниковать.


bsv9
Очевидно, проблема в чем то другом.
Ну раз всё так очевидно - о чём вообще речь ?
Мне вот "очевидно", что вы используете инструменты для "тонкой" работы без реального понимания, что они делают и как ими пользоваться.
И это уже не первый раз.
Мне "очевидно", что вам уже рассказывали и показывали что делать в нештатных ситуациях, но толку от этого ноль - нет ни дампов, ни лок-таблицы - ничего.

Нештатные ситуации были, есть и и будут в любом софте. Ваш случай прошёл бесполезно - из него невозможно извлечь инф-ции для исправления потенциальных ошибок.
сегодня, 09:35    [22160583]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
hvlad
Member

Откуда:
Сообщений: 10954
alekcvp
Если это были maintance процессы, которые выполняли какие-то задачи в момент убийства, то ещё как может.
Это заявление чем-то может быть подкреплено ?
Или срочно нужно было что-то написать ?
И - тожу спрошу - о каких фатальных последствиях речь ?
сегодня, 10:04    [22160607]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
bsv9
Member

Откуда:
Сообщений: 57
hvlad
Мне "очевидно", что вам уже рассказывали и показывали что делать в нештатных ситуациях, но толку от этого ноль - нет ни дампов, ни лок-таблицы - ничего.

Экий вы сегодня злой.

Да, мы уже сталкивались с таким падением, но на виндовом сервере. Сейчас там все готово к снятию дампа памяти процессов и менеджера очередей. С содроганием ждем следующего крэша.
На линуксе в первый раз это случилось, поэтому были не готовы.
сегодня, 10:19    [22160631]     Ответить | Цитировать Сообщить модератору
 Re: Навернулась база Firebird3  [new]
hvlad
Member

Откуда:
Сообщений: 10954
bsv9
Экий вы сегодня злой.
Лучше я буду сегодня "злой", чем вы завтра снова впадёте в панику ;)

bsv9
Да, мы уже сталкивались с таким падением... С содроганием ждем следующего крэша
Не смотря на всю мою злость - не могу запретить вам содрогаться. Так же как не могу запретить ждать того, чего у вас не было. По крайней мере в этой ветке.

bsv9
но на виндовом сервере. Сейчас там все готово к снятию дампа памяти процессов и менеджера очередей...
На линуксе в первый раз это случилось, поэтому были не готовы.
Ну да. На линуксе можно забить на общие рекомендации. Это же линукс. Он целебный сам по себе :)

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

PPS нет, это не отмазки разработчика перед пользователем. Все подтверждённые проблемы мы анализируем и исправляем по мере возможности.
сегодня, 10:53    [22160664]     Ответить | Цитировать Сообщить модератору
Все форумы / Firebird, InterBase Ответить