База и её реплика

Тема в разделе "Lotus - Администрирование", создана пользователем Zeka, 25 мар 2011.

  1. Zeka

    Zeka Well-Known Member

    Регистрация:
    1 сен 2009
    Сообщения:
    219
    Симпатии:
    0
    Где-то слышал, что две реплики одной базы на одном сервере могут стать источником больших проблем.
    Может кто-нибудь сказать, действительно ли это так и какие эти самые проблемы могут быть?

    Меня больше интересует следующий вопрос - а что если на одном сервере расположена и база и её реплика? Есть какие-то подводные камни?

    ПС: Я не админ
     
  2. Sergey Berezka

    Sergey Berezka Гость

    как минимум id реплик отличаться должны
     
  3. puks

    puks Lotus team
    Lotus team

    Регистрация:
    3 фев 2007
    Сообщения:
    1.967
    Симпатии:
    16
    Тогда они, формально, будут копиями, а не репликами. :)
     
  4. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    1.Клиент с сервером такого безобразия сделать не дадут (создать реплику на том-же сервере). Но мы не ищем лёгких путей - добавляем базу на файловом уровне
    2.Если внешний сервер затевает репликацию с сервером-держателем двойной реплики, то какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...
    3.Результат: после нескольких месяцев спокойной жизни ВДРУГ в куче баз по всей сети возникают "зомби" - давно удалённые документы.

    Спортивнее всего насоздавать лишних реплик адресных книг соседних доменов - для сохранности ;)
     
  5. am4

    am4 Гость

    Да запросто (в другой каталог).
    Тут да, не очевидно ;)

    Не совсем понятна постановка задачи, может линками проще обойтись?
     
  6. Zeka

    Zeka Well-Known Member

    Регистрация:
    1 сен 2009
    Сообщения:
    219
    Симпатии:
    0
    Так при описании реплики вроде можно указать, какие фолдеры с какими серверами реплицыровать...
    Хм... Судя по всему, здесь проблемма и начнётся...

    Есть база. Надо запустить DECS для переноса данных в DB2. DECS зараза, при переносе данных, имеет склонность обрезать поля в ноутсовских документах так, что бы по длине они были не больше ширины соответствующих столбиков в DB2. Соответственно даные могут потеряться. Это обрезание полей можно запретить, но тогда DECS вообще не будет перенесить документы с черезмерно длинным полями в DB2.
    Кроме того есть ещё несколько ситуаций когда DECS может поковеркать данные.
    Поэтому возникла "гениальная" идея сделать однонапрвленую реплику базы и разрешить DECS'ку делать в ней чё он хочет и как он хочет.
     
  7. Karpeyev

    Karpeyev Member

    Регистрация:
    6 авг 2008
    Сообщения:
    19
    Симпатии:
    0
    У меня был случай: создали 2 реплики на одном сервере в разных папках.
    Реплицированлись при этом обе реплики, одновременно.
     
  8. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Никаких проблем не будет. Просто надо на сервере настроить репликацию таких баз (с обинаковыми Replicaid) с самим собой (сервер в полях Source server и Destination server тот же самый).
    Такое используется, когда, например, на сервере установлено несколько комплектов Системы, базы с документами, контролями и т.п. разные, а базы со справочными данными одинаковые.
    Но смогут ли помочь БД с одинаковыми репликами для DECS.. - не знаю. Правило из личного опыта: по минимуму использовать готовые реализации от IBM. Под тот же DECS люди програмят и никаких подобных проблем не испытывают (во всяком случае я на такое не натыкался, и о таком не слышал).
     
  9. Baneslaer

    Baneslaer Well-Known Member

    Регистрация:
    25 янв 2011
    Сообщения:
    121
    Симпатии:
    0
    В таком случае не используют миллион реплик, а создают настроечные документы в базе.
    В настроечных доках указывается путь к базам из которых берем инфу.
     
  10. Zeka

    Zeka Well-Known Member

    Регистрация:
    1 сен 2009
    Сообщения:
    219
    Симпатии:
    0
    Вот тут проблема и возникает - в конфигурации репликации указывается с каким сервером какую директорию реплицыровать. И репликатор, основываясь на этом документе, на удалённом сервере (в нашем случае на этом же сервере) будет искать базу с такойже РепликаИД. А вот в какой директории он её будет искать указать нельзя. И какую из двух баз он найдёт - большой вопрос.
     
  11. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Да неужели? ))
    А если мне надо из БД Контрагентов создать Входящий документ (такое часто бывает, т.к. PickList не даёт возможности использовать фильтры, а в самой базе искать нужный док по полнотекстовому поиску легко и удобно), в каком комплекте мне его создавать?

    Повторюсь. Проблем не было. На сервере стояло 4 комплекта баз с одинаковыми репликами; реплицировались все реплики (сразу или нет - деталей не помню, т.к. давно это было).
    Если хотите перестраховаться, то отключите репликацию сервера самим с собой, внутри баз с одинаковыми репликами сделайте агента, который будет толкать репликацию вручную.
     
  12. Baneslaer

    Baneslaer Well-Known Member

    Регистрация:
    25 янв 2011
    Сообщения:
    121
    Симпатии:
    0
    Не совсем понял что имеется в виду, так как документооборот у всех свой.
    насколько я понял, у вас 2 базы - контрагенты и Канцелярия(Входящая/исходящая корреспонденция).
    И создаете вы док непосредственно из базы Контрагентов?
    А что мешает запретить создание доков из базы контрагентов, пусть создают из Канцелярии.
    При этом в канцелярии сделать категоризованную вьюху по контрагентам, если пользователям тяжело искать.

    P.S. Когда на сервере устанавливают несколько комплектов систем, то по фен-шую все справочники создают как копии, кроме справочника организации. Делают это по тем причинам, чтобы не отображать пользователям разных отделов(секретарям) лишнюю информацию при выборе справочных значений(пользователей это нервирвирует). А также это некая защита от удаления справочных значений, когда они завязаны на построение отчетности.
     
  13. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Почему такое предположение? В главном офисе (где это всё установлено) руководители и ответственные лица могут работать во всех комплектах.

    Ну вообще баз далеко не две )

    Запретить мешает то, о чём я писал выше:
    Предлагаемая Вами "категоризированная вьюха по контрагентам" это по сути тот же PickList, а нужен нормальный поиск, с фильтрами.

    Китайские традиции, несомненно, надо уважать, но не всегда выходит по "по фен-шую"... Иногда бывают случаи и одинаковых справочников. И бывают случаи разных справочников организаций.

    Это можно было бы решить маневрированием доступов, группами, например.
    Делается это по той причине, что головная организация хочет контролировать и иметь доступ к информационному полю подчинённых организаций, а подчинённые организации в то же время являются отдельными юридическими лицами...
     
  14. Baneslaer

    Baneslaer Well-Known Member

    Регистрация:
    25 янв 2011
    Сообщения:
    121
    Симпатии:
    0
    документооборот у всех свой, имелось в виду, что у разных организаций своя структура баз и свои системы, какая именно у вас могу только догадываться.

    Ну вообще баз далеко не две ) - в Этом посте говорили именно про связку двух баз. Ясно что их может быть несколько сотен. Придираться к отдельно вырванным из контекста предложениям твое хобби?

    Средств для поиска документа в базе предостаточно, так и не понял что вам неудобно?

    По сути, у вас сейчас разные справочники организаций используются? Демагогия, мне неинтересна.

    Маневрирование доступами очень интересная штука. Особенно, когда сегодня одинаковые справочные значения нужны 2 филиалам, а завтра только одному. И Так каждый день надо дергать админа чтобы прописывал нужную видимость документа. Особенно, для секретарей разных филиалов придется играться с доступами.

    Впервые слышу, чтобы главный офис отслеживал справочные значения у своих филиалов. А если у вас и отслеживает справочные значения, нафига делать 4 реплики одной базы, а не ссылаться на одну единую базу.


    Добавлено: И вообще в нормальных организациях используются единые базы с разграничением доступа, даже для разных юр.лиц.
    Счетчики для документов просто определенным образом привязываются к юр. лицам.
     
  15. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Ваше предложение: запретить создавать доки из справочника контрагентов. Вопрос: имеется организация, например она называется "ООО Весёлый пельмешко", каким образом найдут её пользователи в пиклисте или в категоризированной вьюхе, если один помнит, что в названии есть слово "пельмешко", а другой - "весёлый"?
    Это простой пример, есть и посложнее.

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

    Альтернатива - играться с перебрасыванием доков?

    Вы невнимательно читаете.
    Главный офис отслеживает документооборот, притом некоторые лица могут в нём участвовать. Также репликация - это способ хранения информации у себя, если что...
    Ответ тот же: при создании документов в основных базах из справочных баз не всегда есть возможность понять, в какой базе нужно создавать документ; привязка конкретного пользователя к базе не подходит, т.к. он может работать в нескольких комплектах. Если комплект лежит в одной папке на сервере, тогда понятно, в какой базе с документами создавать док.

    Вообще в нормальных организациях думают наперёд над тем, что будет, если организации разбегутся, как например случилось в Днепропетровске в одном крупном холдинге в 2004-м году: одни директора были за Януковича, другие - за Ющенко, в результате по этой, как бы фонарной, причине, холдинг распался - одни люди ушли со своими заводами в одну сторону, другие со своими - в другую...
    А также люди думают, на каких условиях работает там ПО на филиалах, прописывают права в договорах сублицензирования для определённых условий... и, естественно, такой подход, в виде разделения комплектов, вполне оправдан и, в некотором роде, даже красив.

    P.S. Про счётчики я ничего не говорил, это отдельная тема.
     
  16. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Ну как же неизвестно? Реплицируются все реплики. Другое дело, когда нужно контролировать процес, вот тут могут быть неприятности.

    Думаю, это не очень удачное решение. Лучше использовать некий второй сервер. Хотя, тут все зависит от топологии репликации.

    Все найдет, как уже выше писали.

    Zeka,
    ты бы свою задачу конкретизировал, а то догадки какие-то строишь, а смысл не понятен.
     
  17. Zeka

    Zeka Well-Known Member

    Регистрация:
    1 сен 2009
    Сообщения:
    219
    Симпатии:
    0
    Описывал я её вроде...

    Надо было переносить данные в DB2. Хотели использовать DECS. Но работать с ним надо крайне акуратно, иначе он очень легко может поковеркать значения полей в ноутсовской базе. Поэтому хотели сделать одностаронюю реплику, что бы если ДЕЦС и попортит данные, то только в этой реплике.
    В общем отказались мы от этого убогого ДЕЦСка и написали агентик который прекрасно и безопасно переносит данные.
     
  18. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Zeka ,
    действительно описывал, извини, я пропустил.
    А решение с агентом вполне верное.

    Односторонняя репликя сервера на самого себя в этом случае врядли получилась бы как надо.
     
  19. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Вот-вот. В док-то Connection указывается путь к базе на сервере-инициаторе, про целевой сервер там ничего нет, И быть не может! Там только его имя и, возможно, адрес. О файловой системе удалённого сервера ничего не известно. Возможно, тамошний админ перенёс базу в другой каталог? А может там и каталогов-то нету?? Только тома и минидиски какие-нибудь. Потому что аппаратную платформу тоже поменяли!
    В общем, вызываемому серверу известен ТОЛЬКО ReplicaID базы.
    Поиск базы он производит неслучайным образом (от корня DATA, и далее). Поэтому ОБЫЧНО результат предсказуемый. Но ИНОГДА... то-ли эта база занята, то-ли наоборот - лишняя реплика уже открыта (закеширована)...

    Connection сам с собой никогда не проверял (а сейчас - и не смогу, не админю более). Даже если это и работает (?), то реплик должно быть не более двух. С третьей опять возникнет ситуация непредсказуемости
     
  20. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    У мну на сервере около 50 реплик одной БД и другой сервер вполне себе "перебирает" все и претензий не предъявляет. И когда этот с 50-ю репликами реплицирует на другой сервер, тоже не испытывает проблем.
     
Загрузка...
Похожие Темы - База её реплика
  1. anna
    Ответов:
    3
    Просмотров:
    269
  2. Shandrik
    Ответов:
    13
    Просмотров:
    660
  3. odyssey
    Ответов:
    3
    Просмотров:
    544
  4. iivvnn
    Ответов:
    15
    Просмотров:
    953
  5. anna
    Ответов:
    7
    Просмотров:
    964

Поделиться этой страницей