|
|
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
MolochnikИ еще один вопрос - как можно определить что рестор прошел успешно?Сделать коннект к новой БД. При наличии паранойи - сделать ей валидацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 10:40 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
MolochnikВ 3-ем FB пароли можно менять SQL запросом а не gsec-ом Управлять пользователями через SQL можно начиная с 2.5. Molochnikа запроса на бэкап-рестор так и нет. Это вообще планируется в 4й версии? Нет. И вообще "бекапов" существует как минимум 2 типа. В 4.0 помимо логической репликации есть возможность восстанавливать инкрементные копии прямо в базу данных, это больше похоже на твой способ, но гораздо менее требователен к ресурсам, а потому может работать и на больших БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 11:28 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
m7mПо логу рестора Визуально то понятно, а программно? Формат лога разве специфицирован? m7mнадеюсь удаляешь не файл основной базы ибо появление файла после рестора совсем не означает что рестор прошел успешно Не знал этого, а я надеялся... hvladСделать коннект к новой БД.При наличии паранойи - сделать ей валидацию. А если база восстановилась но не полностью? Валидацию же пройдет. А код завершения gbak? Я немного потестировал, если бэкап или рестор завершились успешно, возвращает 0, иначе 1. На это можно положиться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 12:08 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, Ничего ж себе, вот это сервисы в 4ке! Просто кардинальные изменения - и распределенная база тебе и инкрементный бэкап. В третьем ничего существенного для себя не нашел, разве что перешел на суперсервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 12:13 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
Molochnik, инкрементный бекап был аж с 2.0, но он был не очень надёжным для самой БД. В последних версиях в 2.5 эти ошибки уже поправлены. До 3.0 инкрементный бекап всё равно читал всю БД, в 3.0 читаются только изменённые страницы. В 4.0 основное изменение инкрементного бекапа в том, что инкременты могут применяться к "самой БД" постепенно, а не как раньше полная копия + все инкременты за один раз. Это чем то напоминает физический стендбай. MolochnikВ третьем ничего существенного для себя не нашел, разве что перешел на суперсервер. значит новые возможности SQL и PSQL ещё не осознал или не программист. Molochnik и распределенная база тебе ну это ты погорячился, никакой распределённой БД там нет. Есть логическая синхронная и асинхронная репликация мастер-слейв. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 12:45 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, Я так понял, что инкрементный бэкап в терминологии FB, это когда: Сначала делается основной файл бэкапа, далее - только файлы изменений 1) До 2.5 его использовать было нельзя 2) В последних версиях 2.5 было можно, но не было смысла поскольку время занималось как и при полном, разве что файлы изменений занимали меньше места 3) В 3-ем его стало иметь смысл его использовать поскольку стал очень быстрым 4) в 4-ке рестор можно делать с любого изменения бэкапа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 13:26 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
Симонов Денисну это ты погорячился, никакой распределённой БД там нет. Есть логическая синхронная и асинхронная репликация мастер-слейв. А чем это отличается от распределенной базы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 13:27 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
MolochnikА чем это отличается от распределенной базы? Тем что данные не размазаны, а собраны в одном месте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 13:43 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
Да еще один момент, при ресторе имя файла базы всегда восстанавливается в верхнем регистре независимо от моего желания. Это просто неуважение со стороны FB или это имеет какой смысл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 14:01 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
Molochnik4) в 4-ке рестор можно делать с любого изменения бэкапа не совсем. В 3.0 быстро делается инкрементный бекап, но не рестор. Там для восстановления надо было накатывать по уровням так 0-1-2-3... В 4.0 можно держать почти готовую к использованию БД и всегда накатывать на неё последний инкремент. MolochnikА чем это отличается от распределенной базы? Тем что данные не размазаны, а собраны в одном месте? много чем. В 4.0 реально одна главная БД куда льются изменения, и есть копия (реплика). К ней конечно можно обращаться, но только в Read only режиме. То есть мы можем увеличить производительность за счёт снятия части RO нагрузки, но не пишущей нагрузки. В реально распределённой БД ноды равноправны, главной нет, писать можно в любую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 14:41 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
MolochnikЯ так понял, что инкрементный бэкап в терминологии FB, это когда: Сначала делается основной файл бэкапа, далее - только файлы изменений 1) До 2.5 его использовать было нельзя 2) В последних версиях 2.5 было можно, но не было смысла поскольку время занималось как и при полном, разве что файлы изменений занимали меньше места 3) В 3-ем его стало иметь смысл его использовать поскольку стал очень быстрым 4) в 4-ке рестор можно делать с любого изменения бэкапа Инкрементальный бэкап, точнее бэкапы уровня больше чем 0 (т.е. дельты), на 2,5 работает значительно быстрее чем обычный gbak даже несмотря на то что для этого читает всю базу. В любом случае, рестор из инкрементальных бэкапов делается В РАЗЫ БЫСТРЕЕ чем из gbk, и в каких-то случаях это может быть критичным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2019, 22:09 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
MolochnikА если база восстановилась но не полностью? Валидацию же пройдет.Если база восстановилась из транспортного формата не до конца, то она будет в состоянии shutdown, поэтому самый простой вариант: попытаться подключиться к вновь отресторенной БД непривилегированным пользователем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2019, 09:37 |
|
||
|
Последнее изменение базы
|
|||
|---|---|---|---|
|
#18+
MolochnikЯ так понял, что инкрементный бэкап в терминологии FB, это когда: Сначала делается основной файл бэкапа, далее - только файлы изменений 1) До 2.5 его использовать было нельзя 2) В последних версиях 2.5 было можно, но не было смысла поскольку время занималось как и при полном, разве что файлы изменений занимали меньше места 3) В 3-ем его стало иметь смысл его использовать поскольку стал очень быстрым 4) в 4-ке рестор можно делать с любого изменения бэкапа неправильно понял. nbackup делает либо полную страничную (файловую) копию базы, или производит опять же страничный инкремент, т.е. набор страниц, которые отличаются от предыдущей полной копии или инкремента. По скорости - полная копия базы нбэкапом делается со скоростью копирования файла. Ничего общего с gbak здесь нет, совсем. 1 - да. 2 - нет. 3 - в 3 инкременты делаются быстрее, чем в 2.5 4 - в 4 инкремент можно "накатывать" на копию БД. https://firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/ru/nbackup-ru.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2019, 11:33 |
|
||
|
|
start [/forum/topic.php?fid=40&startmsg=39812168&tid=1560717]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
149ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 292ms |
| total: | 532ms |
| 0 / 0 |
