Вход | Регистрация
 

Клиент хочет репликаю баз 1С между двумя серверами.

Клиент хочет репликаю баз 1С между двумя серверами.
Я
   Гений 1С
 
14.07.20 - 09:05
Чтобы если один вылетит, можно было перейти на второй в течении 1-2 часов.
MS SQL Express 2019 умеет в репликацию?
1С поддерживает репликацию?
Как вариант можно делать бэкапы и копировать их на другой сервак, по идее.
Разностные в течении дня.
MS SQL Express 2019 в бэкапы уж точно умеет.
Кто делал что-то подобное?
   ДенисЧ
 
1 - 14.07.20 - 09:06
А в чём проблема? Средствами скуля сделать репликацию - час работы...
   dka80
 
2 - 14.07.20 - 09:07
Есть варианты: можно репликацию SQL, репликацию виртуальных машин.
   Галахад
 
3 - 14.07.20 - 09:18
Хм. Вот зачем это одинэснику?
   Fish
 
4 - 14.07.20 - 09:22
(0) Делать бэкапы и потом поднимать их - это не репликация. Изучи матчасть.
   Fedor-1971
 
5 - 14.07.20 - 09:44
(0) за 1-2 часа можно развернуть заново сервер и поднять бэкап БД
Давно смотрел в эту сторону, если правильно помню, как средство резервирования репликация не сильно подходит т.к. если упадёт основной, то адресата специально придётся выводить в самостоятельную работу

В результате выработалась примерно следующая схема:
Основной: SQL+1С полностью рабочие
  утром (около 4:00) - полная копия
  каждый час (с 5:00 до 23:00) - разностная копия

Запасной: SQL работает, Сервис 1С спит
  утром (например в 4:40) - копируем с основного полную копию и скриптом грузим в БД SQL (если что посмотреть, то есть вчерашняя копия и её быстро можно восстановить)
  каждый час (5:30 - 23:30) - копируем разностные копии

+ на обеих серверах ограничиваем глубину хранения данных на основном 2-3 дня, на запасном около 14 (на случай посмотреть что творилось в БД, например, в прошлый понедельник)

Если упал основной сервер, то у нас теряется по максимуму последний час работы, восстановление работоспособности 1С - примерно 20-30 минут, при удачном стечении обстоятельств - около 15 минут

Если критичен лаг потери данных, то можешь организовать разностную копию через 30 минут ну и копирование через каждые 15 минут.

При копировании сбрасывай флаг Архивный у файлов, тогда не будет гоняться по сети весь объём копии, а только последние изменённые файлы (в идеале 1 последняя копия)
   arsik
 
6 - 14.07.20 - 09:46
(0) Postgre поставь, он это умеет (WAL).
   vcv
 
7 - 14.07.20 - 10:12
(5) "за 1-2 часа можно развернуть заново сервер и поднять бэкап БД"
И какого у вас размера ДБ, что за час-два разворачивается из бэкапа с подъёмом сервера?

(0) Самый простой в настройке вариант, это AlwaysON. Позволяет иметь всегда актуальную копию базы на другом сервере. Можно настроить автоматическую отработку отказа, когда при выходе одного сервера из строя всё автоматом переключается на другой.
Только говорят, что по быстродействию не самый хороший вариант. Гилёвцы для 1С рекомендовали репликацию Log shipping.
   vcv
 
8 - 14.07.20 - 10:14
Express никакой репликации и тем более AlwaysOn не умеет. С ним, по моему, только через backup/restore. Можно днём перегонять только журналы транзакций, днём полный бэкап.
   Seriy_Volk
 
9 - 14.07.20 - 10:18
(7) +1 за  Log shipping, но версия MS SQL должна быть выше Express редакции.
   Fedor-1971
 
10 - 14.07.20 - 10:24
(7) в развёрнутом виде 30 Гиг, в бэкапе 5.7
Если есть резевный комп, готовый образ винды и выгрузки (бэкапы), ничего не мешает поднять новый сервер за 1 час
Если озаботиться сохранением выгрузок на внешний диск, то и доставать с поломанной машины ничего не понадобится, просто подключаем и забираем недостающие бэкапы (если диск не долбануло при выходе из строя основного сервера, для того и нужно копирование на запасной сервер)
   vcv
 
11 - 14.07.20 - 10:53
(10) "в развёрнутом виде 30 Гиг, в бэкапе 5.7"
С учетом того, что ТС помянул express, соглашусь с вами. Но в общем подобные оценки времени выглядят очень оптимистично. Вот у меня более 3Тб нужных баз. И это совсем не 1-2 часа на поднятие из бэкапа.

(0) https://docs.microsoft.com/ru-ru/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-ver15
Вот тут пишут, что express не имеет никаких возможностей репликации. Так что только через backup/restore.
   Fedor-1971
 
12 - 14.07.20 - 11:15
(11) Тут всё зависит от требований к времени восстановления, в Вашем раскладе я бы разбросал по нескольким серверам критичные БД и прописал в регламенте восстановления БД1/Сервер1 - Резервный Сервер2, БД2/Сервер2 - резервный Сервер3, БД3/Сервер3 - резервный Сервер1. Вероятность поломаться одновременно 3-м компам не очень большая, а если их ещё разнести по разным помещениям или хотя-бы стойкам ещё меньше.

Т.е. если что-то сломалось идём на указанный сервер и поднимаем из копии БД (копии туда уже сложены или загружены средствами SQL), в штатном режиме блокируем работу с резервной БД или чистим оную (что-бы не получить "А я случайно не туда данные внесла").

У такой схемы есть преимущество - не нужно думать чем занять резервные сервера на время штатной работы основного
   Гений 1С
 
13 - 14.07.20 - 11:49
База 10 ГБ (база и лог) в модели Симпл.
Ну да, там Экспресс.
Придется, видимо, через бэкап.

Второй сервак развернут, там другие базы крутятся, но можно эту перенести оперативно.
Как то первый сервак вылетел, так я вручную перенес файл базы и лога SQL на другой
   wt
 
14 - 14.07.20 - 12:08
Кластер серверов.
http://catalog.mista.ru/public/907443/
   timurhv
 
15 - 14.07.20 - 12:44
(13) с таким объемом я бы не о репликации думал, а о редакции SQL. В итоге встанут колом оба сервера.
   vcv
 
16 - 14.07.20 - 12:55
(13) >> База 10 ГБ (база и лог) в модели Симпл.
Посмотрите размер самой базы. Без лога. Как бы не влететь в проблемы неожиданно.
МС пишет (ссылку я давал выше):
Максимальный размер реляционной базы данных    10 ГБ
   Гений 1С
 
17 - 14.07.20 - 13:44
А чем лучше бы синхронизировать FTP на серваке с IIS кто подскажет?
   Гений 1С
 
18 - 14.07.20 - 13:45
(16) говорю же - с логом вместе
   timurhv
 
19 - 14.07.20 - 15:36
(18) лог может и 100мб весить, тогда час Х придет очень быстро
   Гений 1С
 
20 - 14.07.20 - 15:42
(19) не, лог там намного выше базы, смотрел
   Гений 1С
 
21 - 14.07.20 - 16:04
(16) посмотрел 3 и 3.5 базы там.
   Гений 1С
 
22 - 14.07.20 - 16:04
Причем это где-то за 3 года эксплуатации такие объемы.
   Serg_1960
 
23 - 14.07.20 - 16:11
А чем клиенту/автору РИБ не нравится?
   Фрэнки
 
24 - 14.07.20 - 16:18
(23) это же его кто-то должен попробовать. Наверное, еще не пробовал.
   Fedor-1971
 
25 - 14.07.20 - 16:34
(23) Проблема в 2-х одновременно работающих серверах, велика вероятность события "Ой, не туда внесла", либо делать ДМЗ и прятать туда вторую БД
   Serg_1960
 
26 - 14.07.20 - 18:18
(25) Все пользователи работают только в одной базе. Это легко организовать.
   mikecool
 
27 - 14.07.20 - 18:36
(22) сколько же средний чек у него, за три года такие объемы - накладная в сутки чтоли?
   Гений 1С
 
28 - 14.07.20 - 19:14
(23) гм, это идея. Но типовые в РИБ разве гоняют все данные? Там вечно забывают какой-нибудь объект включить в план обмена. Не, усложнение на пустом месте.
   Гений 1С
 
29 - 14.07.20 - 19:15
(27) думаю, чеков 20 за день, на сумму 50к в день.
   Фрэнки
 
30 - 14.07.20 - 19:31
(28) нет, конечно. Первичный образ можно устроить из копии базы - данные будут абсолютно идентичные, а дальше нужно просто посмотреть абсолютно все будут обмениваться данные или нет.
Как правило, в конфигурации Полный РИБ есть.
 
 Рекламное место пустует
   Сияющий в темноте
 
31 - 14.07.20 - 23:41
какой риб
ставим в базу подписку на запись - в ней объект уже есть в памяти и отправляем его или кролику или еще кому-то,кто передает на другую машину,а там минисервер (ну он на пять подключений,а у нас будет 0),чтобы полученное писать в базу.
и все,при аварии потеряется то,что еще не передано (и то,что пользователи не успели записать,для некоторых и это трагедия)-переставляем ключ в другую машину,и она готова к работе.
   NuclearWinter
 
32 - 14.07.20 - 23:46
Поставить PostgreSQL и настроить реплику
   Сергиус
 
33 - 15.07.20 - 00:02
(0)План обмена в фоне средствами 1с.
   stopa85
 
34 - 15.07.20 - 00:37
(17) rsync
   acht
 
35 - 15.07.20 - 07:17
(31) > ставим в базу подписку на запись
О, еще один любитель общаться с внешними системами из транзакций.
А потом следующая подписка отменяет транзакцию и ты можешь засунуть всю "релмикацию" именно вот туда.
   acht
 
36 - 15.07.20 - 07:17
^"репликацию"
   Обработка
 
37 - 15.07.20 - 07:48
Давно было.
1. база 1с77 на скуле 2000
2. Полный бекап ночью в 3 часа
3. Днем каждые 15 мин разностный бекап.
4. Бекапы делались сразу на два сервера.
5. основной сервер имел диски с горячей заменой и был с избытком в один диск. (Hot Swap и Hot Sрear) так вроде звались.
6. Что бы не переименовывать имена на сервере использовал псевдонимы имен  DFS.
В тесовых переходах успевали перейти на новый сервер в 40 минут с потерей данных в 15 минут.

Но реальный аварийный переход я устроил за большее время. Ошибка в том что в спешке я указывал старый сервак в место нового или на старую базу не помню.
Тут нужно быть очень собранным и внимательным!
   Сияющий в темноте
 
38 - 15.07.20 - 09:20
(35) подписка должна быть последней.
потом,проверить,что операция в транзакции можно и даже нужно,чтобы для каждого объекта не выполнять код.
   Serg_1960
 
39 - 15.07.20 - 09:27
Я не фанат РИБ, но... имхо:
Бэкапирование/репликация средствами SQL информационных баз 1С увеличивает вероятность возникновения недостоверных / противоречивых / разрушенных данных с точки зрения 1С при воссоздании копии базы. Чем чаще используются механизмы SQL (по расписанию) - тем выше вероятность. Например, документы без движений или движения без документов; записи справочников или документов без табличных частей; объекты, не включенные в журналы; неверно индексированные, битые служебные данные и т.д.

С этой точки зрения (получение непротиворечивых данных в базе) механизм РИБ платформы - более предпочтителен. Этот механизм платформы всё-таки функционирует в парадигме 1С и с учётом её правил работы с объектами. Низкая вероятность возникновения противоречивых/разрушенных данных доказана многолетней практикой использования РИБ в 1С.
   Конструктор1С
 
40 - 15.07.20 - 09:51
(0) Чтобы если один вылетит, можно было перейти на второй в течении 1-2 часов

Вылетит по какой причине? Может всё-таки лучше тщательнее проработать вопрос бэкапирования? Сервер понадёжнее там, RAID, положить БД, журнал транзакций и архивы БД на отдельные физические диски, и вот это вот всё
   acht
 
41 - 15.07.20 - 13:40
(38) Не может. Согласно документации вендора, порядок выполнения подписок неопределен.
См, например, https://its.1c.ru/db/v8313doc#bookmark:dev:TI000000212 : третий пункт после "При наступлении указанного события выполняется следующая последовательность действий"

Возражения "а вот на практике, у меня" можешь сразу отбросить. Потому как расширения разных типов (исправление/адаптация) и т.п.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.