Как мигрировать большую 10+ Тб базу 1С из MS SQL в PostgreSQL и уложиться в трехчасовое окно

Тема перехода на PostgreSQL весьма популярна, и почти на каждой конференции по PG обязательно есть парочка докладов на эту тему. Почему же эта тема до сих пор злободневна? Когда мы начинали свой блог здесь на Хабре, наша первая статья была посвящена как раз задаче перевода больших баз данных MSSQL –> PostgreSQL. И первой причиной, из-за которой компании решаются на переход мы называли законодательство. А именно, необходимость для государственных и окологосударственных организаций, чьи информационные системы относятся к значимым объектам критической информационной инфраструктуры (ЗОКИИ) переводить свою работу на отечественное ПО. Прошло два года. И это всё еще основная причина. Это не будет инструкция в стиле «делай раз», «делай два». Это будет про то, что большие базы в принципе очень тяжело и рискованно передвинуть (СУБД, платформа, окружение,…). И мы предлагаем собственный метод, как это сделать с гарантией отсутствия простоев бизнеса. Даже если что-то пойдет не так в «новой» системе, пользователи не должны страдать, а бизнес простаивать. Это главное!

https://habr.com/ru/companies/softpoint/articles/921038/

#миграция_бд #postgresql #переход_MSSQL_PostgreSQL #MSSQL2PostgreSQL #dbreplication

1С РИБ опять тормозит. Как лечить?

Назрела тут тема про обмены между базами данных 1С. Даже сузим круг и поговорим об обменах между гомогенными базами данных (базами данных с идентичными конфигурациями). Ситуации когда бизнес предпочитает распределенные информационные системы централизованным системам – далеко не редкость. И чем ИТ-система больше, чем больше в ней пользователей и транзакций в единицу времени, тем сложнее поддерживать обмен между ее узлами на плаву. Обмен частенько тормозит и становится помехой пользователям и даже бизнесу...

https://habr.com/ru/companies/softpoint/articles/835542/

#РИБ #обмен_1с #dbreplication #perfexpert #ускорение_обмена_1С #распределенные_базы_данных

Миграция терабайтной базы 1С: УПП с платформы 1C 8.1 на 8.3

Продолжаем обсуждать вопросы, связанные с миграцией больших баз данных. Сегодня поговорим про, казалось бы, обыденный случай – обновление платформы 1С. Большие базы, как обычно, накладывают свои ограничения на все процессы обновления/обслуживания/конвертации. Есть много рисков, которые необходимо предусмотреть на берегу, подстелить соломки, чтобы не получить простои системы и бизнеса. Статья получилась не совсем обычная, потому что писалась она в соавторстве с заказчиком по результатам успешного завершения проекта миграции. Соответственно, здесь будет сразу два взгляда на один и тот же проект.

https://habr.com/ru/companies/softpoint/articles/820637/

#perfexpert #dbreplication #datacluster #Много_Мебели #Обновление_платформы_1С #миграция_бд #большая_база_данных

Миграция с MSSQL Server на PostgreSQL. Предпосылки

Сегодня обсудим общие вопросы, связанные с миграцией баз данных на новую платформу. Как обычно, акцент сделан на системах 1С:Предприятие, как самых популярных на российском рынке. Но многие рекомендации универсальны и годятся для всех ИТ-систем.

https://habr.com/ru/companies/softpoint/articles/806127/

#миграция_бд #posgresql #perfexpert #репликация_баз_данных #dbreplication #sql_server #переход_на_PostgreSQL #миграция_1С

Бэкап, бэкап и еще раз бэкап

Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости. Почему вроде бы правильно настроенное архивирование базы данных не всегда помогает спасти систему в случае инцидентов? Этим вопросом я, наверное, многих даже задел за живое. Одних тем, что сама постановка вопроса им кажется абсурдной – у этой группы админов все настроено идеально, работает как часы и они готовы к любым катаклизмам. А кого-то тем, что напоминаю о тех самых инцидентах, когда возвращаться в тот день, даже мысленно, совсем не хочется. В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости. И если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря. Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.

https://habr.com/ru/companies/softpoint/articles/795305/

#DB_Replication #dbreplication #репликация_базы_данных #отказоустойчивость #резервирование #бэкап #шифровальщик #цод #sql #восстановление_баз_данных