Начало » Использование СУБД » Firebird, HQbird, InterBase » Предел кол-ва транзакций для БД
| Предел кол-ва транзакций для БД [сообщение #4915] |
Wed, 17 April 2024 17:31  |
H.e.l.p
Сообщений: 9
Зарегистрирован: July 2022
|
Junior Member |
|
|
Привет всем!
FB 2.5.9, Classic, dialect 1
Oldest transaction 2096672242
Oldest active 2098476520
Oldest snapshot 2098460621
Next transaction 2098814732
Прирост транзакций примерно 1,2 - 1,5 млн. в день.
Наткнулся на комментарий kdv из форума "кстати, заранее предупреждаю. с такой интенсивностью транзакций, если еще и будет расти, через 1.5-2 года база остановится, и ей надо будет делать срочно перевод в readonly, потом бэкап-рестор."
Правильно я понимаю, что у меня этот срок наступит через месяц? Или это уже не актуально?
[Обновления: Wed, 17 April 2024 18:32] Известить модератора |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4924 является ответом на сообщение #4918] |
Thu, 18 April 2024 09:57  |
basid
Сообщений: 167
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Senior Member |
|
|
H.e.l.p писал(а) Thu, 18 April 2024 01:21Что можно придумать для БД размером 1,8Т, бекап/рестор идет двое суток, такой простой просто не допустим. У вас, как бы, два варианта:
1. Организовать запланированный простой минимальной длительности;
2. Аварийно встать "когда случится".
P.S.
Про HQbird уже упомянули. Ускорит (финальный) этап построения индексов.
Добавлю про потоковый бэкап-рестор (минимизация времени и диска на передачу данных из "старой" базы в "новую".
Если ПО может работать с базой "только чтение", то можно выполнить всё тот же потоковый бэкап-рестор из RO-базы с последующим быстрым переключением.
Совсем экзотический вариант - выполнить передачу данных (gbak -i) и "распараллелить" построение индексов разных таблиц специально подготовленным скриптом. Но проще - использовать HQbird: он распараллелит построение индексов в рамках отдельной таблицы. Что заметно ускорит построение индексов на больших и очень больших таблицах при не самых отстойных дисках.
[Обновления: Thu, 18 April 2024 09:58] Известить модератора |
|
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4927 является ответом на сообщение #4925] |
Thu, 18 April 2024 12:02 |
neozx1984
Сообщений: 27
Зарегистрирован: June 2022
|
Junior Member |
|
|
Для Linux:
1) Запускаем сессию screen.
2) В первой сессии screen выполняем команду
gbak -v -y backup.log -g -b database stdout | lzop -1 -o database.gbk.lzo
3) Во второй сессии screen не дожидаясь завершения бекапа выполняем команду
tail -c+0 -f database.gbk.lzo | lzop -dc | gbak -v -y restore.log -o -i -r stdin database-br
4) Активируем индексы утилитой plume в несколько потоков
plume -u sysdba -p masterkey -t N -d localhost:ncore-fssp
P.S. По пункту 4 могут быть разные нюансы. Если есть очень большие индексы возможно их лучше восстанавливать в один поток, т.к. большие файлы сортировки сожрут всю память(если временные файлы на tmpfs) или диск.
P.P.S. plume - распараллеливает построение индексов, потребление памяти в этом случае растет.
P.P.P.S. Так же необходимо провести тестовый рестор, т.к. возможны сюрпризы с null в не null полях и другие фокусы с метаданными.
[Обновления: Sat, 22 June 2024 23:18] от Модератора Известить модератора |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4935 является ответом на сообщение #4925] |
Fri, 19 April 2024 09:57 |
basid
Сообщений: 167
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Senior Member |
|
|
H.e.l.p писал(а) Thu, 18 April 2024 16:18Два вопроса Вопросов, на самом деле, три, поэтому отвечаю не по порядку.
Многопоточный бэкап параллельно вычитывает данные из разных мест одной таблицы. Потоки, естественно, ничего не пропускают по общему итогу и не конкурируют друг с другом "внутри" базы.
Многопоточный рестор ускоряет только восстановление индексов, точно также вычитывая данные для сортировки в несколько потоков.
Данные, которые читаются из бэкапа, вставляются в (очередную) таблицу в один поток. На этом этапе просто нечего параллелить.
"Потоковый бэкап-рестор" это вполне себе общеизвестная концепция "труба-конвейер" (pipe) и организовывается он как и любой другой конвейер: процесс1 | процесс2
Или даже: процесс1 | ... | процессN
Следует чётко разграничивать регулярные и разовые задачи.
Ежедневный бэкап (с восстановлением, как минимум, метаданных) - задача регулярная. Время бэкап важно, но не критично.
"Перебэкап" базы для сброса значений счётчиков транзакции, в обозримой перспективе - задача разовая.
Для разовой задачи критичным является общее время. Не просто важно, а именно, что критично - есть всего одна попытка и минимум времени: amat victoria curam.
В данном случае, теоретический возможный минимум - время восстановления "новой" базы, поэтому doc/README.services_extension.txt и ("сложено"):"bin/gbak" -se service_mgr ... -b -g база stdout 2>full.bkp.err |
"bin/gbak" -se service_mgr ... -c -use_ stdin новая-база 2>full.rst.err
При восстановлении обязательно указываются -v, -y и -st, чтобы в протоколе было видно сколько времени заняли этапы восстановления.
Процесс всегда начинается с бэкапа-восстановления только метаданных:gbak -se ... -m -b -g база stdout | gbak -se ... -m -c stdin мета-база
Для 32-разрядного - до гигабайта-гигабайта с четвертью. Может быть и до полутора гигабайт, но это уже надо смотреть отдельно и будет зависеть от разрядности операционки.
Большой TCL, в любом случае, несколько (или даже существенно) ускорит построение индексов при восстановлении базы.
Разрядность посмотреть "в сведениях о реализации":"bin/fbsvcmgr" service_mgr ... info_implementation -z Firebird services manager version WI-V2.5.9.27152 Firebird 2.5
Server implementation: Firebird/x86-64/Windows NT
Firebird services manager version WI-V2.5.9.27139 Firebird 2.5
Server implementation: Firebird/x86/Windows NT
Диск, на который будет восстанавливаться новая база, должен быть быстрым. Если быстрый диск только один и он занят "старой" базой, то будет чуть сложнее и займёт больше времени.
|
|
|
|
|
|
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4986 является ответом на сообщение #4953] |
Sun, 28 April 2024 01:12 |
H.e.l.p
Сообщений: 9
Зарегистрирован: July 2022
|
Junior Member |
|
|
Привет!
Еще раз спасибо всем за советы!
По плану:
1. Запланировали простой работы в 48 часов (с запасом) для пишущих сервисов (кроме критичных). Для читающих - без ограничений.
2. На новом сервере развернули триальный HQBird.
3. С помощью nbackup залочили БД, скопировали на новый сервер (1 час 40 мин, 1.4Т)
4. Остановили сервер БД. Скопировали дельту (4.5Г). Запустили сервер, разлочили БД и подняли сервисы. Простой 30 мин.
5. Запустили бекап в HQBird, 12 потоков - 1 час 50 минут
6. Запустили рестор в HQBird, 12 потоков - чистое время 12 часов 52 минуты.
Через два часа работы служба аварийно остановилась и рестор пришлось перезапускать (The Firebird Server - HQBirdInstanceFB2 service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 0 milliseconds: Restart the service.) Почему так произошло хз, в журналах ничего подозрительного не обнаружилось. На предварительных тестах все было нормально, как в боевом прогоне - так подлянка ))
7. Остановили сервисы, поменяли алиас на старой базе, что бы больше никто не вносил изменений. Скопировали дельту по критичным таблицам (скриптами), выровняли значения всех генераторов. Простой 1 час.
8. Зарезолвили путь к продной БД на новый IP, запустили все сервисы.
Итого: БД была полностью недоступна для сервисов 1 час 30 минут. Простой пишущих сервисов 17 часов.
[Обновления: Sun, 28 April 2024 01:17] Известить модератора |
|
|
|
Переход к форуму:
Текущее время: Tue Dec 31 09:42:42 GMT+3 2024
Общее время, затраченное на создание страницы: 0.00929 секунд
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
