SDC работает с группой серверов использующих штатную асинхронную потоковую репликацию. Поэтому, всегда нужно делать выбор, что более критично для вашей системы, либо потерять какую-то часть данных, либо получить простой (RTO и RPO). В ситуации, когда мастер пропал, сессии на нём прервутся, транзакции не зафиксируются. Если не настроен Failover, то SDC будет ждать пока появится мастер, и возможно реплика к нему. Данное решение производится автоматически. Есть возможность задать в настройках SDC скрипт, который будет выполняться при потере мастера ( Т.е. может повысить реплику до мастера автоматически.) Возвращаясь к вашему вопросу, в теории возможна ситуация, когда транзацкция успела зафиксироваться на мастере, но не успела отреплицироваться, и мастер пропал. Это тот риск, о котором я сказал в первом предложении. Но, если мастер всё-таки восстановится без смены ролей серверов, то WAL прокачаются в большинстве случаев и потерь данных не будет.
Данное ограничение необходимо для обеспечения стабильности работы механизмов системы, осуществления поддержки и возможности перехода на новые версии «1С:Предприятия».
Если выполняется данное условие, то какие проблемы?
Тут в целом есть тонкости, то со своей колокольни, я бы отключал overcommit (т.е. стратегия OVERCOMMIT_NEVER), а vm.overcommit_ratio равным 80-90. Можно вообще запретить OOM киллеру трогать PG, но зачем...
Данная статья по настройкам памяти именно внутри Postgres'a, чтобы у пользователя было понимание как и что устроено. Стратегии overcommit в данном случае относятся косвенно. Вопрос лишь в том, целиком ли postmaster срубит OOM или только какой-то отдельный процесс.
В описании системы репликации на сайте разработчика именно это и указано – внедряется без доработки конфигурации 1С, изменения данных передаются непосредственно из таблицы в таблицу на уровне SQL Server, передача данных может быть двунаправленной и однонаправленной. Отзывы вроде всё это подтверждают.
А что касается «неплохой механизм быстрого переноса/конвертации/свертки данных, когда пользователи отключены», то в статье как раз утверждается, что с использованием системы репликации пользователей можно не отключать в рабочей базе. Вероятно для определённых ситуаций, например, терабайтная база с высокой интенсивность изменения данных и отсутствием тех. окон, подход с репликацией будет иметь преимущества перед методикой РИБ’а.
Исходя из какого описания сделан вывод о том, что с типовыми конфигурациями 1С решение не может работать без проблем? Судя по описанию на сайте разработчика https://softpoint.ru/solutions/db-replication/ , система репликации совместима с любыми конфигурациями 1С.
О том же, "чем помешал обычный РИБ", в статье вроде есть резонные для высоконагруженной БД аргументы – доп. нагрузка и блокировки БД MSSQL, проблематика синхронизации БД PGSQL с оперативными данными БД MSSQL за время конвертации в PGSQL, и др.
Лицо человека не относится к персональным данным. Согласно п.1 ч.2 ГК РФ Статья 152.1. «Охрана изображения гражданина» изображение получено законно.
Также можете ознакомиться с Разъяснениями Роскомнадзора «О вопросах отнесения фото- и видео- изображения, дактилоскопических данных и иной информации к биометрическим персональным данным и особенности их обработки»
И соответственно на второй ваш вопрос ответ прост, фотография лица не является персональными данными.
SDC работает с группой серверов использующих штатную асинхронную потоковую репликацию. Поэтому, всегда нужно делать выбор, что более критично для вашей системы, либо потерять какую-то часть данных, либо получить простой (RTO и RPO).
В ситуации, когда мастер пропал, сессии на нём прервутся, транзакции не зафиксируются.
Если не настроен Failover, то SDC будет ждать пока появится мастер, и возможно реплика к нему. Данное решение производится автоматически.
Есть возможность задать в настройках SDC скрипт, который будет выполняться при потере мастера ( Т.е. может повысить реплику до мастера автоматически.)
Возвращаясь к вашему вопросу, в теории возможна ситуация, когда транзацкция успела зафиксироваться на мастере, но не успела отреплицироваться, и мастер пропал.
Это тот риск, о котором я сказал в первом предложении. Но, если мастер всё-таки восстановится без смены ролей серверов, то WAL прокачаются в большинстве случаев и потерь данных не будет.
.
Там вот у 1С ещё приписка есть...
Если выполняется данное условие, то какие проблемы?
Тут в целом есть тонкости, то со своей колокольни, я бы отключал overcommit (т.е. стратегия OVERCOMMIT_NEVER), а vm.overcommit_ratio равным 80-90. Можно вообще запретить OOM киллеру трогать PG, но зачем...
Данная статья по настройкам памяти именно внутри Postgres'a, чтобы у пользователя было понимание как и что устроено. Стратегии overcommit в данном случае относятся косвенно. Вопрос лишь в том, целиком ли postmaster срубит OOM или только какой-то отдельный процесс.
А в контексте чего вопрос?
Вопрос, безусловно, интересный, но, вероятно, его стоит задать непосредственно компании 1С. Кроме них никто не знает об их планах.
Не совсем из принципа. Многие и хотели бы вести дела, но тут уже будут репутационные риски, а рынок в России несколько меньше чем в Европе.
Как получить официальный дистрибутив?
В описании системы репликации на сайте разработчика именно это и указано – внедряется без доработки конфигурации 1С, изменения данных передаются непосредственно из таблицы в таблицу на уровне SQL Server, передача данных может быть двунаправленной и однонаправленной. Отзывы вроде всё это подтверждают.
А что касается «неплохой механизм быстрого переноса/конвертации/свертки данных, когда пользователи отключены», то в статье как раз утверждается, что с использованием системы репликации пользователей можно не отключать в рабочей базе. Вероятно для определённых ситуаций, например, терабайтная база с высокой интенсивность изменения данных и отсутствием тех. окон, подход с репликацией будет иметь преимущества перед методикой РИБ’а.
Исходя из какого описания сделан вывод о том, что с типовыми конфигурациями 1С решение не может работать без проблем? Судя по описанию на сайте разработчика https://softpoint.ru/solutions/db-replication/ , система репликации совместима с любыми конфигурациями 1С.
О том же, "чем помешал обычный РИБ", в статье вроде есть резонные для высоконагруженной БД аргументы – доп. нагрузка и блокировки БД MSSQL, проблематика синхронизации БД PGSQL с оперативными данными БД MSSQL за время конвертации в PGSQL, и др.
Первый раз вижу заключение о некомпетентности исполнителя, апеллируя к положительному отзыву клиента о работе исполнителя ?
Вы статью читали целиком или тезисно?
Также можете ознакомиться с Разъяснениями Роскомнадзора «О вопросах отнесения фото- и видео- изображения, дактилоскопических данных и иной информации к биометрическим персональным данным и особенности их обработки»
И соответственно на второй ваш вопрос ответ прост, фотография лица не является персональными данными.
Отсюда и получается эта небольшая разница.
Ну и да, это не группы, это время, каждый столбик — час.