• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Как правильно проверять, среплицировался ли документ на сервер или нет

  • Автор темы fedotxxl
  • Дата начала
F

fedotxxl

Гм... интересная задачка...
Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
Пусть условие такое - в промежутки между репликацией документ может меняться только на одном сервере.
 
A

Akupaka

извини, но это бредовое условие :unsure:
"все познается в сравнении". вывод - надо что-то с чем-то сравнить.

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

Kee_Keekkenen

Гм... интересная задачка...
Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
можно проверить была ли репликация после изменения документа, а вот дошел ли это вряд ли.. чтоб сравнивать нужно брать документы из обоих баз и их сравнивать..
 
30.05.2006
1 345
12
BIT
0
Запись в журнал репликации пишется после успешного завершения сеанса. Т.о. если сеанс был, значит все документы дошли.

PS: это все, конечно, в предположении, что репликатор работает безошибочно
 
F

fedotxxl

Есть парочка идей:
1. Нам известно какое поле мониторить на какое значение (условно говоря). Т.е. при генерации действия я задаю @ формулу, на основании которой оно исполнится.... Вариант плох тем, что не автоматический
2. Быть может на разнице дат изменения документов?... нужен какой-то автоматический вариант
 
A

Akupaka

мы об одном и том же говорим? :rolleyes:
что ты подразумеваешь под "автоматическим" вариантом?..
ты либо шире описывай мысли, либо... не знаю...
в данном случае краткость не сестра... ;)
 
F

fedotxxl

У меня изменился документ на сервере А. Нужно подождать, пока обновится на сервере Б и что-то сделать.
1. Я знаю, что у меня изменилось в документе. Тогда я пишу это в виде @ формулы,например {Status = "1"}. Когда у меня на Б у документа поле Status станет равно "1", это будет означать, что реплика дошла. Такой вариант плох тем, что мне нужно знать, что изменилось
2. Если я не знаю, что у меня поменялось, то, по-моему... теоретически можно сравнивать даты изменения документа... как вам такой вариант?
 
K

Kee_Keekkenen

не ясна конечная цель такого отслеживания..
 
A

Akupaka

не ясна конечная цель такого отслеживания..
могу предположить, что это можно использовать для уведомления пользователей об изменениях в документе... правда, довольно тяжелый способ :rolleyes:

fedotxxl, ты уже знаком с агентами? посмотри справку по агентам, trigger On event, After documents are created or modified
именно с помощью такого агента я предлагал тебе (первый ответ) реализовать проверку.
кроме того, что ты так пытаешься привязаться к собакам? скрипт не знаешь? изучай тогда, он будет подинамичнее для подобной задачи...
 
R

rins

Гм... интересная задачка...
Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
Пусть условие такое - в промежутки между репликацией документ может меняться только на одном сервере.


имхо - завести поле Field_B и если на сервере B Field_B<>LastModified то это для ЭТОГО сервера новый\измененный док. Провести обработку и записать в Field_B LastModified.
Вместо LastModified можно заюзать иные признаки факта изменения док-та.
Кста - факт Field_B=LastModified означает для сервера А, что док-ты точно дошли до сервера В и там обработались.
 
30.05.2006
1 345
12
BIT
0
имхо - завести поле Field_B и если на сервере B Field_B<>LastModified то это для ЭТОГО сервера новый\измененный док. Провести обработку и записать в Field_B LastModified.
Вместо LastModified можно заюзать иные признаки факта изменения док-та.
До конца не просеку, но какой-то гнильцой по-пахивает: сервера такой пинг-понг этими отметками начнут...
Давайте еще раз:
Кто должен убедиться в успешности репликации? Отправитель?
Достоверно это можно сделать только сравнением всех полей документа на обоих серверах. Собственно системный репликатор этим и занимается. Написать еще один и запускать в-догонку за системным? :blink: Лажа какая-то...

Не 100%-ная, но гораздо более простая проверка:
Сравнить время модификации док-та с записью в журнале репликации: если репликация с сервером NNN успешно завершилась после LastModified документа, значит этот док-т уже на сервере NNN
 
A

Akupaka

бррр... а если у нас 5 серверов? то по полю на сервер?..
 
R

rins

бррр... а если у нас 5 серверов? то по полю на сервер?..

да хоть 555. жалко что ли? :blink: Тем более там вьюха будет одна на все сервера с формулой отбора по ...бла-бла ...@Enviroment("ServerName")...


До конца не просеку, но какой-то гнильцой по-пахивает: сервера такой пинг-понг этими отметками начнут...
Это не пинг-понг - это неизбежные издержки offline систем. Обмен чеками о принятии док-та - единственно надежный способ контроля доставки до получателя.

Не 100%-ная, но гораздо более простая проверка:
Сравнить время модификации док-та с записью в журнале репликации: если репликация с сервером NNN успешно завершилась после LastModified документа, значит этот док-т уже на сервере NNN

Это очень не надежно - например если мы задействуем readers поля, то все-приплыли.
Не говоря уж о парсинге ошибок репликации из-за АСЛ например.
Можно конечно сбацать свой репликатор и через API и юзая структуру
Type REPLFILESTATS
TotalFiles As Long
FilesCompleted As Long
NotesAdded As Long
NotesDeleted As Long
NotesUpdated As Long
Successful As Long
Failed As Long
NumberErrors As Long
End Type
... чегой-то там осмыслить - только эт все лажа полнейшая...
 
A

Akupaka

не жалко, но зачем?..
имхо, достаточно простого сравнения, которое я в самом начале предлагал - записывать в момент редактирования в поле имя сервера, который провел изменения, на каждом из серверов работает агент по новым и измененным докам, если агент подымает документ, в котором имя сервера в поле не совпадает с именем его сервера, то этого достаточно чтобы определить, что документ был изменен и требуется выполнить какое-то действие...
 
R

rins

Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?

кста - для небольшого количества серверов есть еще один способ - игрища с фолдерами :blink:
Т.е. сервер Б банально складывает новые док-ты в свою, по имени сервера папку :)


не жалко, но зачем?..
имхо, достаточно простого сравнения, которое я в самом начале предлагал - записывать в момент редактирования в поле имя сервера, который провел изменения, на каждом из серверов работает агент по новым и измененным докам, если агент подымает документ, в котором имя сервера в поле не совпадает с именем его сервера, то этого достаточно чтобы определить, что документ был изменен и требуется выполнить какое-то действие...

Вот только я никак не пойму... как в таком случае сервер А узнает, что документ добрался до сервера Б ??? Неужели по признаку, что поле с содержимым сервер_А поменялось на сервер_Б ? а если еще один сервер добавить?

Короче - надо конкретику. Есть конечно подозрение, что все сводится к задаче :"...ссылка на документ по почте, когда документ еще не среплицировался на локальный сервер..."
 
A

Akupaka

Вот только я никак не пойму... как в таком случае сервер А узнает, что документ добрался до сервера Б ??? Неужели по признаку, что поле с содержимым сервер_А поменялось на сервер_Б ? а если еще один сервер добавить?
хо... хорошее замечание :blink: я задачу понял как "выполнить что-нить на сервере Б, когда док изменен на сервере А и был реплицирован на сервер Б"

а вообще, то хорошо было бы узнать чего хотят достичь и зачем так поставлена задача...
 
30.05.2006
1 345
12
BIT
0
бррр... а если у нас 5 серверов? то по полю на сервер?..
Вот-вот, именно! Все будут генерить отметки про всех контрагентов и провоцировать новую репликацию на все остальные сервера. УжОссс...


Это очень не надежно - например если мы задействуем readers поля, то все-приплыли.
...
Обмен чеками о принятии док-та - единственно надежный способ контроля доставки до получателя.
Вот-вот. READERS-поля влияют на надежность репликации. Замечательно, очень свежо

И: репликация - не отсылка датаграмм, а ДВУХСТОРОННИЙ процесс. Журнал коммитится только при успешной синхронизации

Дырка в "моей" схеме конечно есть, но Вы её не видите
 
R

rins

Вот-вот, именно! Все будут генерить отметки про всех контрагентов и провоцировать новую репликацию на все остальные сервера. УжОссс...
Про неизбежность накладных расходов я уже говорил. Их можно уменьшить - но эт уже детали.
Вот-вот. READERS-поля влияют на надежность репликации. Замечательно, очень свежо
И: репликация - не отсылка датаграмм, а ДВУХСТОРОННИЙ процесс. Журнал коммитится только при успешной синхронизации
Все же еще раз озвучу свое ИМХО, не отвлекаясь на мелочи - НЕ опиратся на ТРАНСПОРТНЫЕ механизмы подтверждения передачи данных, а использовать как окончательный вердик только подтверждение ПРИКЛАДНОЙ системы, как конечную цель.
Дырка в "моей" схеме конечно есть, но Вы её не видите
Ест-сно. я много чего не вижу и многое не знаю:( "На всякого мудреца - довольно простоты" :blink:
 
30.05.2006
1 345
12
BIT
0
Про неизбежность накладных расходов я уже говорил. Их можно уменьшить - но эт уже детали.
Нельзя. "Дьявол скрывается в деталях"(с)
Все же еще раз озвучу свое ИМХО, не отвлекаясь на мелочи - НЕ опиратЬся на ТРАНСПОРТНЫЕ механизмы подтверждения передачи данных, а использовать как окончательный вердикТ только подтверждение ПРИКЛАДНОЙ системы, как конечную цель.
Вот-вот. Репликация - не транспортный механизм, а весьма прикладная система (хотя и часть платформы). Транспорт - это NRPC и, м.б. почта. Лепить на репликации свои средства доставки можно, но шаблонно применять к ним "традиционные" дата-граммные подходы/приемы, не учитывая специфику внутренних механизмов репликации (контроля целостности в т.ч.) - по меньшей мере неграмотно
 
K

Kee_Keekkenen

Сравнить время модификации док-та с записью в журнале репликации: если репликация с сервером NNN успешно завершилась после LastModified документа, значит этот док-т уже на сервере NNN
может статься что время репликации всегда позже, чем время сохранения документа, и тогда придется хранить информацию о предпоследней репликации..
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!