Комментарии 14
Скажите, а какая была причина миграции с MS SQL на PostgreSQL ?
Подозреваю, что эта
Скажите, а как изменилось общее число коров и памяти после перехода, пришлось увеличивать?
Сейчас, спустя несколько месяцев суммарные аппаратные мощности примерно соответствуют тем же, что были на MS. Примерно, потому что теперь каждый сервер PG - это отдельный инстанс, а ранее на одном инстансе MS могли крутиться одновременно несколько БД. Но если у вас одна БД, то можно сказать, что аппаратные ресурсы по итогам могут остаться такими же.
Здесь необходимо придерживаться следующего сценария. Сразу после перехода потребление ресурсов на СУБД возрастет (особенно по памяти). Необходимо об этом помнить и обязательно иметь на сервере PG запас по памяти, дискам и CPU. Далее идет период тюнинга (несколько недель) - читаем цикл наших статей про память. Универсальных настроек, подходящих всем, нет! Поэтому хорошо бы иметь инструментарий и компетенции, чтобы не работать с PG как с черным ящиком.
После тюнинга СУБД, запросов, индексов эффективность использования памяти и др. ресурсов выходит на уровень не хуже MS и избыточные ресурсы можно убрать. В этом мы убедились уже на нескольких проектах.
Но при этом, в пиковый момент переезда получалось удвоение необходимых мощностей, чтобы держать все MS + все PG инстансы, верно? А процесс перехода на Linux 1C мог идти на высвобождаемых MS 1C серверах.
И ещё вопрос по срокам - только первый этап озвучен в 4 месяца. А у остальных не указаны сроки. Сколько заняли последующие этапы?
Отдельный инстанс на одном сервере? Или отдельный инстанс на отдельном сервере?
Второе - отдельный инстанс на отдельном сервере (виртуальном).
Те. Раньше на одном mssql было 10 бд 1с, стало 10 серверов с одной бд 1с.
Стоит аналогичная проблема , пока все плохо выходит, для галочки да можно импортозаместится, но для оптимальности и производительности, экономней -нет
Те. Раньше на одном mssql было 10 бд 1с, стало 10 серверов с одной бд 1с.
Использование виртуальных машин очень помогает оптимизировать использование ресурсов. К тому же, вам не обязательно идти по этому пути.
Что касается "для галочки/не для галочки", то цели перехода у всех разные. Кто-то это делает в добровольно-принудительном порядке, кто-то по иным причинам.
Цель статьи не в этом. Мы хотели показать, что, во-первых, перейти можно без рисков прерывания пользовательской работы и простоев системы, а, во-вторых, производительность системы будет не хуже, чем была на MS.
Как перевести 40 распределенных баз 1С из MSSQL в PostgreSQL