Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
subj Будут ли ошибки целостности в базе, восстановленной из такого бэкапа? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 09:27 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Насколько я понимаю процесс бэкапа нет. Бэкап идет в три шага В первом замораживается внесение изминений WIJ в базу и выполняется ее поблочный бэкап в следующих двух шагах идет добавление внесенных с момента заморозки блоков.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 09:44 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
А т.е. тут участвуют не журналы, а WIJ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 10:03 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Параллельно у меня висит монитор системы, и судя по нему время от времени сброс данных в базу все-таки происходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 10:04 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н., а как вы определили, что это именно сброс в базу? Возможно, это сброс в WIJ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 10:24 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Журналы просто переключаются при бэкапе для удобства дальнейшего восстановления, те восстановил бэккап и дальше по журналам.... Там много проходовый сброс, поэтому можно делать бэкап при работе сервера (записи в базу) Конечно лучше для бэкапа использовать время с минимальнй нагрузкой на WIJ (те когда данные в базе не меняются или изменения минимальны) например ночью. При этом время сохранения/востановления и размер файла бэкапа будут минимальными, за счет минимизации дополнительных проходов (сброс изминенных с момента заморозки блоков) Хотя можно и делать внешний бэкап, заморозка системы, копирования базы, востановление работы системы или использовать специализированное железо для горячего бэкапа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 10:32 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Параллельно у меня висит монитор системы, и судя по нему время от времени сброс данных в базу все-таки происходит. А что за монитор используеш? Какая версия Каше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 10:36 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
gr_vlХотя можно и делать внешний бэкап, заморозка системы, копирования базы, востановление работы системы или использовать специализированное железо для горячего бэкапаПробовал внешний бэкап. На самом деле, замораживается только демон записи, процессы продолжают работать, а измененные данные - накапливаться в кэше глобалов вплоть до истечения таймаута (умолчание - 10 минут) или до заполнения кэша. Только если наступает одно из этих событий, замораживается вся система. Подробности см. док-ю класса Backup.General, метод ExternalFreeze. В нормальных условиях (когда параллельно никто гигабайты в БД не заливает :) даже небольшого (512Мб) кэша хватает за глаза, впрочем этот момент каждый может сам оценить, исходя из статистики работы свое системы (кол-ва физических записей блоков в минуту). Немного напрягает здесь только одно: "классический" бакап всё же хорошо интегрирован с журналом, восстановил его - и тебе сразу предлагают восстановиться по журналу, причём, начиная с правильного файла. А в случае внешнего бакапа выбор журнала для восстановления должен делать админ, т.е. добавляется человеческий фактор. gr_vl, насчёт специализированного железа: может быть есть конкретный опыт, которым вы захотите с нами поделиться? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 11:54 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Alexey MaslovБлок А.Н., а как вы определили, что это именно сброс в базу? Возможно, это сброс в WIJ. База на отдельном диске. Каше 2009.1.6. Смотрю виндовым монитором обычным, Control Panel\Administrative Tools\Perfomance. Временами скачок записи секунд на 20, потом длительная тишина порядка минуты. Результат бэкапа не критичен, т.е. если он будет кривой - скажу "упс" и сделаю заново. Просто интересует, вот если я сейчас сжатие базы или дефрагментацию запущу (а они в журнал тоже не пишут), то как оно сможет чисто теоретически сделать адекватный бэкап? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 13:19 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н., если виндовый монитор, то как он отличит запись в БД от записи в WIJ, от записи в *.cbk и т.д.? Разве что они у вас разнесены по разным дискам... Тут мониторить изнутри Cache надо, например GLOSTAT'ом, задавая интервал времени меньший, чем время бакапа. Как уже сказал gr_vl, здесь главное, чтобы запись шла в WIJ, а не в журнал. Все операции с БД пишут в WIJ (так уж устроен демон записи), так что можно не волноваться насчёт дефрагментации и пр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 14:08 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н., пардон, не заметил, что база у вас на отдельном диске. Возможно, сброс в БД всё же происходит (но всё же я помониторил бы GLOSTAT), но в какие-то безопасные моменты. Например, после записи очередной накопленной порции блоков из WIJ в .cbk вроде бы безопасно записать её и в базу, хотя бы для того, чтобы WIJ не разрастался. Заметьте, что интервал сброса около 1 минуты довольно велик, в нормальных условиях интервал сброса буферов меньше, где-то 10-15 сек, если не ошибаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 14:21 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н., Адекватно было бы если при запуске выдалоы сообщение что база заблокирована идет дефрагментация или бэкап..... А вообще, чисто теоритически может и получите адэкватный бэкап, но меня терзают сомнения что он может быть в несколько раз больше базы. Если будете эксперементировать, сообщите результаты. И еще по поводу монитора активности, блоки базы помечаются для возможности выполнения полного инкриментного или комулятивного бэкапа. Так что может быт вы эту активность и наблюдали..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 14:24 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
gr_vlБлок А.Н., Адекватно было бы если при запуске выдалоы сообщение что база заблокирована идет дефрагментация или бэкап..... А вообще, чисто теоритически может и получите адэкватный бэкап, но меня терзают сомнения что он может быть в несколько раз больше базы. Если будете эксперементировать, сообщите результаты. И еще по поводу монитора активности, блоки базы помечаются для возможности выполнения полного инкриментного или комулятивного бэкапа. Так что может быт вы эту активность и наблюдали..... Те уточняю при изменение блока данных на нем устанавливается признак что он был изменен с последнего полного или инкрементного бэкапа, а при выполнении бэкапа этот признак с блока попавшего в бэкап убирается.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 14:32 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Про инкрементные бэкап мне сильно кажется, что он делается только по журналам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 15:13 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Про инкрементные бэкап мне сильно кажется, что он делается только по журналам. Для бєкапа журналі не используются!!!!! Если делаешь не полный бэкап используются блоки измененные с последнего полного бэкапа(инкриментный) или изминенные после последнего, любого бэкапа(комулятивный)!! Информация об изминенных блоках хранится в самой базе! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 16:02 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
[quot Alexey Maslov]gr_vl gr_vl, насчёт специализированного железа: может быть есть конкретный опыт, которым вы захотите с нами поделиться? :) Друзья использовали RAID с горячей заменой SATA2 У меня все проще останавливается Каше, копируются базы, запускается Каше, запускается архивирование и после передача архива на фтп где уже ручками запись на носитель.... На утро имеем копию базы за предыдущий день и зарезервированную, готовую к записи копию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 17:39 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
gr_vl, Спасибо, так оно и есть. В принципе это более логичный и надежный способ, но почему-то я был уверен, что используются именно журналы. Но в качестве метки наверняка используется не системное время, а что-то другое, потому что поломать логику бэкапа играясь с системным временем у меня не получилось. Получается, журналы используются только для транзакций? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2011, 19:12 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.gr_vl, Спасибо, так оно и есть. В принципе это более логичный и надежный способ, но почему-то я был уверен, что используются именно журналы. Но в качестве метки наверняка используется не системное время, а что-то другое, потому что поломать логику бэкапа играясь с системным временем у меня не получилось. Получается, журналы используются только для транзакций? -- Для зеркалирования (теневой сервер), -- транзакций, -- востановления данных (от последнего бэкапа и до последнего момента (или нужной даты) -- для «поиска вредителй» (кто что скоректировал в базе....) -- для формирования почты (выборки изменении) для филиалов (сброс изминений справолчников и тд) off-line (те формируется выборки в файл, для каждого предприятия свои маски отбора данных и потом пересылается с главного офиса на удаленный филиал, с филиала в главный офис (Рабоатет на удаленных филиалов где нет постоянной связи и работает автономный локальный серер Cache). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2011, 14:08 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.gr_vl, Спасибо, так оно и есть. В принципе это более логичный и надежный способ, но почему-то я был уверен, что используются именно журналы. Но в качестве метки наверняка используется не системное время, а что-то другое, потому что поломать логику бэкапа играясь с системным временем у меня не получилось. Получается, журналы используются только для транзакций? Используется не время а бит признак был ли блок изминен с последнего полного или инкрмиентного бэкапа..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2011, 14:11 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
[quot gr_vl]Блок А.Н.gr_vl, -- для формирования почты (выборки изменении) для филиалов (сброс изминений справолчников и тд) off-line (те формируется выборки в файл, для каждого предприятия свои маски отбора данных и потом пересылается с главного офиса на удаленный филиал, с филиала в главный офис (Рабоатет на удаленных филиалов где нет постоянной связи и работает автономный локальный серер Cache). А как вы журнал разделяете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2011, 17:04 |
|
||
|
бэкап с одновременным параллельным внесением данных при отключенном журналировании
|
|||
|---|---|---|---|
|
#18+
[quot Блок А.Н.]gr_vlпропущено... А как вы журнал разделяете? Пересылается не сам журнал а файл сформированный с выборками из журнала, те в Cache есть api для извлечения из журнала данных типа: -тип операции -база и узел глобала -значение узла и еще несколько В зависимости от узла определяем нужна ли эта корректировка на каком нибудь филиале (Для каждого филиала заведены справочники, согласно которым идет отбор данных), если да то изменения попадают в файл предназначенный для отправки этому филиалу (на самом деле несколько сложнее), упростил для понимания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2011, 00:23 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=37248907&tid=1557750]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
35ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 360ms |

| 0 / 0 |
