|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Симонов ДенисПорицается не использование shutdown, а бессмысленное использование backup/restore. Точнее backup нужен всегда, а вот постоянный рестор для уменьшения БД абсолютно бессмысленное занятие. Но мой вопрос именно про shutdown, backup/restore используется совсем не часто, но используется и эффект есть... А гораздо чаще я использую shutdown для подмены базы в интеграционных тестах, но это не имеет отношения к теме.. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:52 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudПлюс нужно придумать механизм для оповещения, в том числе и удалённых приложений (без доступа к ФС). http://www.sql.ru/forum/187250 http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf http://firebirdsql.org/file/documentation/reference_manuals/reference_material/Firebird-2_5-LangRef-Update-Russian.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:53 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudЕсли не использовать механизм shutdown, то для удаления базы надо как-то оповестить все приложения о том что эта база готовится к удалению еще можно попробовать отстрелить соединения с помощью monitoring tables вроде бы, но говорят не всегда хорошо получается а сервер - супер или классик? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:55 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Arioch http://www.sql.ru/forum/187250 http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf http://firebirdsql.org/file/documentation/reference_manuals/reference_material/Firebird-2_5-LangRef-Update-Russian.pdf Спасибо, но это вариант не подходит, т.к. приложению еще нужно понять что подсоединяться к БД можно, а как сделать это не соединяясь с ней? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 13:54 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochа сервер - супер или классик? SS... Но хотелось бы, конечно, универсальное решение... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 13:58 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudAriochа сервер - супер или классик? SS... Но хотелось бы, конечно, универсальное решение... просто на классике можно отстреливать через процессы попробуй отключать всех через мониторинговые таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 15:54 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudприложению еще нужно понять что подсоединяться к БД можно, а как сделать это не соединяясь с ней? а как оно это поймёт в случае shutdown'a ? сделай после события достаточно большую паузу между пересоединениями чтобы все успели отключиться и shutdown успел отработать Либо уже заводи отдельную цетнрализованную БД "доступность рабочих БД" и пуст ьвсе аппликухи туда поглядывают. Заодно сможешь сделать веб-страничку "статус наших баз данных" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 15:56 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochvitkudпропущено... SS... Но хотелось бы, конечно, универсальное решение... просто на классике можно отстреливать через процессы попробуй отключать всех через мониторинговые таблицы. не забудь прибить sweep заодно. очень полезно для здоровья базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 16:33 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochа как оно это поймёт в случае shutdown'a ? в случае shutdown force 0 база сразу переходит в shutdown и обычные пользователи не могут подключиться, но это работало до 2.5.3. А в 2.5.3-2.5.6 все зависают... А shutdown attach с таймаутом не получатся использовать, потому как он не только "замораживает" попытки открытия баз, но и попытки закрытия, и если в одном потоке несколько соединений, то поток ждёт пока не закончится таймаут у shutdown'а, и только потом закрывает все соединения, а сам shutdown, соответственно, завершается неудачей... Ariochсделай после события достаточно большую паузу между пересоединениями чтобы все успели отключиться и shutdown успел отработать получается что нельзя запускать shutdown пока все не отключатся, а как узнать что все отключились? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 17:24 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudа как узнать что все отключились? через мониторинговые таблицы от SYSDBA ну или таки сделай все же центральную БД доступности ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 17:34 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, ну и да, служебные пoдключения типа sweep'a тоже учитывай ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 17:34 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudбаза остаётся огромных размеров... например? 100 гиг, 500 гиг? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 20:20 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudSS... Но хотелось бы, конечно, универсальное решение...Самым универсальным решением будет написать управляющую службу по типу fbguard, которая по отдельному tcp порту будет "рассказывать" клиентам о состоянии службы сервера и баз данных, а также, при необходимости, производить все необходимые манипуляции по shutdown'у баз, остановки службы сервера и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 10:04 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudКак вообще организовать shutdown базы, если есть приложение с пулом соединений? Почему-то при попытке shutdown базы с ключом -attach приложение зависает на попытке закрытия одного соединения до тех пор пока не закончится timeout у shutdown'а... "-at[tach] : this parameter prevents any new connections to the database from being made with the exception of the SYSDBA and the database owner. The shutdown will fail if there are any sessions connected after the timeout period has expired. It makes no difference if those connected sessions belong to the SYSDBA, the database owner or any other user." Gfix - Database Housekeeping -> Database Startup and Shutdown Что мешает рубануть запросом в isql из имени SYSDBA или владельца БД все пользовательские соединения, пока выполняется: gfix -shut -attach <timeout> <db> ? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 10:16 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
*из isql от имени SYSDBA P.S. И почему на форуме не сделана возможность исправления своих сообщений? Не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 10:18 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_dev, 1) потому что NNTP 2) потому что тролли этим пользовались, чтобы задним числом удалять компромат ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 11:38 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
kdvнапример? 100 гиг, 500 гиг? Ха, бывает что в системе всего 32 гига, а нужно еще место для бэкапов.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 11:46 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudбывает что в системе всего 32 гига, а нужно еще место для бэкапов.. Если бэкапы делаются на тот же диск, где и сама база, то можно сэкономить: вообще их не делать. Всё равно они совершенно бесполезны. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 11:53 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_dev "-at[tach] : this parameter prevents any new connections to the database from being made with the exception of the SYSDBA and the database owner. The shutdown will fail if there are any sessions connected after the timeout period has expired. It makes no difference if those connected sessions belong to the SYSDBA, the database owner or any other user." Gfix - Database Housekeeping -> Database Startup and Shutdown Да в описании всё хорошо, но на практике, вызывая gfix -shut -attach <timeout> мы блокируем клиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного)... rdb_devЧто мешает рубануть запросом в isql из имени SYSDBA или владельца БД все пользовательские соединения, пока выполняется: gfix -shut -attach <timeout> <db> ? Я просто не знал что есть такая возможность... пойду искать как это делается.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 12:43 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudно на практике, вызывая gfix -shut -attach <timeout> мы блокируем клиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного)...Это что-то новое ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 13:47 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudЯ просто не знал что есть такая возможность... пойду искать как это делается..Вот как-то так: Код: cmd 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 14:57 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Вот же кривущий форматтер!... Не забудь убрать лишние строки, особенно после строк, заканчивающихся на ^ ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 14:58 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladЭто что-то новое Вот скрипт на Groovy: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
который создаёт пустую базу, открывает 3 соединения к ней, и пытается перевести её в режим shutdown в течении 20 сек. Параллельно, в отдельном потоке, пытается закрыть по одному соединению в секунду. Но при попытке закрыть первое же соединение, поток "замирает" до неудачного завершения shutdown'а, и только после этого закрывает остальные соединения. Вот такой вывод у меня в консоль: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:25 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudПараллельно, в отдельном потоке, пытается закрыть по одному соединению в секунду. Но при попытке закрыть первое же соединение, поток "замирает" до неудачного завершения shutdown'а, и только после этого закрывает остальные соединения.Есс-но. Оно же всё в одном потоке. У тебя в примере нет никаких vitkudклиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного).Ибо кроме gfix'а есть ровно один клиент, который что-то там хочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:43 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Проверил с isql: запустил 3 штуки isql запустил gfix -shut -force 0 он висит в каждом isql делаю exit - никакого ожидания, мгновенный дисконнект с ошибкой database shutdown на попытках коммита своих тр-ций. Если сделать commit заранее (сразу после старта isql и до запуска gfix) - никаких ошибок на exit нет. После последнего дисконнекта gfix просыпается и тоже отключается, без ошибки ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:48 |
|
|
start [/forum/topic.php?fid=40&msg=39314177&tid=1561952]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 163ms |
0 / 0 |