Как обновить postgresql 1c

Обновлено: 21.11.2024

Начиная с Zulip 3.0, Zulip поддерживает ряд версий PostgreSQL. PostgreSQL 14 в настоящее время используется по умолчанию для новых установок; Поддерживаются PostgreSQL 10, 11, 12 и 13.

Предыдущие версии Zulip использовали любую версию PostgreSQL, которая была включена в базовую операционную систему (например, PostgreSQL 12 в Ubuntu 20.04). Мы рекомендуем обновить установки, использующие старые версии PostgreSQL, до PostgreSQL 14, так как мы можем отказаться от поддержки старых версий PostgreSQL в будущих версиях.

Удаленная база данных PostgreSQL

Если вы хотите использовать удаленную базу данных PostgreSQL, вам следует настроить информацию о соединении с сервером. Вам нужен пользователь с именем «zulip» на вашем сервере базы данных. Вы можете настроить эти параметры в файле /etc/zulip/settings.py (приведенные ниже описания взяты из документации PostgreSQL):

REMOTE_POSTGRES_HOST : имя или IP-адрес удаленного хоста

отключить: меня не волнует безопасность, и я не хочу платить за шифрование.

разрешить: меня не волнует безопасность, но я оплачу накладные расходы на шифрование, если на этом будет настаивать сервер.

prefer: меня не волнует шифрование, но я хочу оплатить накладные расходы на шифрование, если сервер его поддерживает.

verify-ca: я хочу, чтобы мои данные были зашифрованы, и я принимаю накладные расходы. Я хочу быть уверен, что подключаюсь к серверу, которому доверяю.

verify-full: я хочу, чтобы мои данные были зашифрованы, и я принимаю накладные расходы. Я хочу быть уверен, что подключаюсь к серверу, которому доверяю, и что это именно тот сервер, который я указал.

Затем следует указать пароль пользователя zulip для базы данных в файле /etc/zulip/zulip-secrets.conf:

Наконец, вы можете остановить свою базу данных на сервере Zulip с помощью:

В будущих версиях этой функции мы хотели бы реализовать и задокументировать, как автоматически подключаться к самому удаленному серверу базы данных PostgreSQL с помощью сценария установки Zulip с набором манифестов Puppet, отличным от универсальной функции; если вы хотите поработать над этим, отправьте сообщение в список рассылки разработчиков Zulip, и мы дадим вам несколько советов.

Отладка проблем с базой данных PostgreSQL

При отладке проблем с PostgreSQL, в дополнение к стандартному инструменту pg_top, часто бывает полезно использовать этот запрос:

который показывает запущенные в данный момент серверные части и их активность. Это похоже на выходные данные pg_top с дополнительным преимуществом, заключающимся в отображении полного запроса, что может быть полезно при отладке.

Чтобы остановить неуправляемый запрос, вы можете запустить SELECT pg_cancel_backend(pid int) или SELECT pg_terminate_backend(pid int) от имени пользователя postgres. Первый отменяет текущий запрос серверной части, а второй завершает внутренний процесс. Они реализуются путем отправки процессам сигналов SIGINT и SIGTERM соответственно. Мы не рекомендуем отправлять SIGKILL процессу PostgreSQL. Это приведет к тому, что база данных прервет все текущие подключения, отменит все ожидающие транзакции и перейдет в режим восстановления.

Останов базы данных Zulip PostgreSQL

Чтобы запустить или остановить PostgreSQL вручную, используйте команду pg_ctlcluster:

По умолчанию при использовании остановки используется «интеллектуальный» режим, который ожидает отключения всех клиентов перед закрытием базы данных. Это может занять непозволительно много времени. Если вы используете опцию –force с остановкой, pg_ctlcluster попытается использовать «быстрый» режим для завершения работы. «Быстрый» режим описан на странице руководства следующим образом:

С параметром –force используется «быстрый» режим, который откатывает все активные транзакции, немедленно отключает клиентов и, таким образом, корректно завершает работу. Если это не сработает, снова будет предпринята попытка выключения в «немедленном» режиме, что может оставить кластер в несогласованном состоянии и, таким образом, привести к выполнению восстановления при следующем запуске. Если и это не помогает, процесс postmaster уничтожается. Выход с 0 в случае успеха, с 2, если сервер не работает, и с 1 в других условиях сбоя. Этот режим следует использовать только тогда, когда машину собираются выключить.

Многие параметры базы данных можно настроить во время работы базы данных. Просто измените /etc/postgresql/9.1/main/postgresql.conf и выполните перезагрузку. В журналах будут отмечены изменения.

Отладка проблем при запуске PostgreSQL

pg_ctlcluster часто не предоставляет никакой информации о том, почему не удалось запустить базу данных. Он может предложить вам проверить журналы, но вы не найдете там никакой информации. pg_ctlcluster запускает следующую команду ниже, когда она фактически запускает PostgreSQL:

Поскольку pg_ctl не перенаправляет stdout или stderr, выполнение описанного выше может дать вам более точную диагностическую информацию. Однако вы можете остановить PostgreSQL и перезапустить его с помощью pg_ctlcluster после отладки с использованием этого подхода, так как он пропускает часть работы, которую выполняет pg_ctlcluster.

Оповещения об очистке PostgreSQL

Предупреждение autovac_freeze PostgreSQL от check_postgres особенно важно.Это предупреждение указывает, что возраст (с точки зрения количества транзакций) самого старого идентификатора транзакции (XID) приближается к настройке autovacuum_freeze_max_age. Когда самый старый XID достигает этого возраста, PostgreSQL принудительно выполняет операцию VACUUM, что часто может привести к внезапному простою до завершения операции. Если этого не сделать и возраст самого старого XID достигнет 2 миллиардов, произойдет зацикливание идентификатора транзакции и произойдет потеря данных. Чтобы очистить предупреждение nagios, выполните VACUUM в каждой указанной базе данных в качестве суперпользователя базы данных ( postgres ).

pg_upgrade -b старый_каталог -B новый_каталог_привязки -d старый_каталог_конфигурации -D новый_каталог_конфигурации [ option< /эм> . ]

Описание

pg_upgrade (ранее называвшийся pg_migrator ) позволяет обновлять данные, хранящиеся в файлах данных PostgreSQL, до более поздней основной версии PostgreSQL без сброса/перезагрузки данных, которые обычно требуются при обновлении основной версии, например, с 9.5.8 до 9.6.4 или с с 10,7 по 11,2. Это не требуется для промежуточных обновлений версии, например, с 9.6.2 до 9.6.3 или с 10.1 до 10.2.

В основные выпуски PostgreSQL регулярно добавляются новые функции, которые часто изменяют макет системных таблиц, но редко меняется внутренний формат хранения данных. pg_upgrade использует этот факт для выполнения быстрых обновлений путем создания новых системных таблиц и простого повторного использования старых файлов пользовательских данных. Если будущий основной выпуск когда-либо изменит формат хранения данных таким образом, что старый формат данных станет нечитаемым, pg_upgrade нельзя будет использовать для таких обновлений. (Сообщество постарается избегать таких ситуаций.)

pg_upgrade делает все возможное, чтобы старый и новый кластеры были совместимы с двоичными файлами, например, проверяя совместимые параметры времени компиляции, включая 32/64-разрядные двоичные файлы. Важно, чтобы любые внешние модули также были бинарно-совместимы, хотя это нельзя проверить с помощью pg_upgrade .

pg_upgrade поддерживает обновление с версии 8.4.X и выше до текущего основного выпуска PostgreSQL, включая моментальные снимки и бета-версии.

Параметры

pg_upgrade принимает следующие аргументы командной строки:

старый исполняемый каталог PostgreSQL; переменная среды PGBINOLD

новый каталог исполняемых файлов PostgreSQL; по умолчанию это каталог, в котором находится pg_upgrade; переменная среды PGBINNEW

проверить только кластеры, не изменять данные

-d каталог_конфигурации
--old-datadir= каталог_конфигурации

старый каталог конфигурации кластера баз данных; переменная среды PGDATAOLD

-D configdir
--new-datadir= configdir

новый каталог конфигурации кластера баз данных; переменная среды PGDATANEW

количество одновременных процессов или потоков для использования

использовать жесткие ссылки вместо копирования файлов в новый кластер

параметры, которые будут переданы непосредственно старой команде postgres; добавлено несколько вызовов опций

параметры, которые будут переданы непосредственно новой команде postgres; добавлено несколько вызовов опций

старый номер порта кластера; переменная среды PGPORTOLD

номер порта нового кластера; переменная среды PGPORTNEW

сохранять файлы SQL и журналов даже после успешного завершения

каталог, который будет использоваться для сокетов postmaster во время обновления; по умолчанию текущий рабочий каталог; переменная среды PGSOCKETDIR

имя пользователя установки кластера; переменная среды PGUSER

включить подробное внутреннее ведение журнала

отобразить информацию о версии, затем выйти

Используйте эффективное клонирование файлов (также известное как «ссылки» в некоторых системах) вместо копирования файлов в новый кластер. Это может привести к почти мгновенному копированию файлов данных, давая преимущества скорости -k / --link, оставляя старый кластер нетронутым.

Клонирование файлов поддерживается только в некоторых операционных системах и файловых системах. Если он выбран, но не поддерживается, запуск pg_upgrade завершится ошибкой. В настоящее время он поддерживается в Linux (ядро 4.5 или более поздней версии) с Btrfs и XFS (в файловых системах, созданных с поддержкой reflink), а также в macOS с APFS.

показать справку, затем выйти

Использование

Вот шаги для выполнения обновления с помощью pg_upgrade :

При желании переместите старый кластер

Если вы используете каталог установки для конкретной версии, например, /opt/PostgreSQL/13 , вам не нужно перемещать старый кластер. Все графические установщики используют каталоги установки для конкретных версий.

Если ваш каталог установки не зависит от версии, например, /usr/local/pgsql , необходимо переместить текущий каталог установки PostgreSQL, чтобы он не мешал новой установке PostgreSQL. После выключения текущего сервера PostgreSQL можно безопасно переименовать каталог установки PostgreSQL; предполагая, что старый каталог /usr/local/pgsql , вы можете сделать:

чтобы переименовать каталог.

Для установки из исходного кода соберите новую версию

Создайте новый исходный код PostgreSQL с флагами конфигурации, совместимыми со старым кластером. Перед началом обновления pg_upgrade проверит pg_controldata, чтобы убедиться, что все настройки совместимы.

Установите новые двоичные файлы PostgreSQL

Установите двоичные файлы нового сервера и вспомогательные файлы. pg_upgrade включен в установку по умолчанию.

Для исходных установок, если вы хотите установить новый сервер в произвольном месте, используйте префиксную переменную:

Инициализировать новый кластер PostgreSQL

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

Установить общие объектные файлы расширений

Многие расширения и пользовательские модули, как из contrib, так и из другого источника, используют общие объектные файлы (или библиотеки DLL), например, pgcrypto.so . Если они использовались в старом кластере, общие объектные файлы, соответствующие новому двоичному файлу сервера, должны быть установлены в новом кластере, как правило, с помощью команд операционной системы. Не загружайте определения схемы, например, CREATE EXTENSION pgcrypto, потому что они будут продублированы из старого кластера. Если доступны обновления расширений, pg_upgrade сообщит об этом и создаст скрипт, который можно будет запустить позже для их обновления.

Копировать пользовательские файлы полнотекстового поиска

Скопируйте любые пользовательские файлы полнотекстового поиска (словарь, синоним, тезаурус, стоп-слова) из старого в новый кластер.

Настроить аутентификацию

pg_upgrade будет подключаться к старому и новому серверам несколько раз, поэтому вы можете установить одноранговую аутентификацию в pg_hba.conf или использовать файл ~/.pgpass (см. Раздел 33.15).

Остановить оба сервера

Убедитесь, что оба сервера баз данных не используются в Unix, например:

или в Windows, используя правильные имена служб:

Резервные серверы потоковой репликации и доставки журналов могут продолжать работать до следующего шага.

Подготовка к обновлению резервного сервера

Если вы обновляете резервные серверы с помощью методов, описанных в разделе Шаг 11, убедитесь, что старые резервные серверы подключены, запустив pg_controldata для старых основного и резервного кластеров. Убедитесь, что значения «Расположение последней контрольной точки» совпадают во всех кластерах. (Возможно несоответствие, если старые резервные серверы были отключены раньше, чем старые первичные, или если старые резервные серверы все еще работают.) Кроме того, убедитесь, что в файле postgresql.conf в новом первичном кластере для параметра wal_level не установлено минимальное значение.

Запустить pg_upgrade

Всегда запускайте двоичный файл pg_upgrade нового сервера, а не старого. pg_upgrade требует указания старых и новых каталогов данных и исполняемых файлов ( bin ) кластера. Вы также можете указать значения пользователя и порта, а также указать, хотите ли вы, чтобы файлы данных были связаны или клонированы вместо поведения копирования по умолчанию.

Если вы используете режим ссылки, обновление будет намного быстрее (без копирования файлов) и займет меньше места на диске, но вы не сможете получить доступ к своему старому кластеру после запуска нового кластера после обновления. Режим связи также требует, чтобы старый и новый каталоги данных кластера находились в одной и той же файловой системе. (Табличные пространства и pg_wal могут находиться в разных файловых системах.) Режим клонирования обеспечивает те же преимущества в скорости и дисковом пространстве, но не делает старый кластер непригодным для использования после запуска нового кластера. Режим клонирования также требует, чтобы старый и новый каталоги данных находились в одной и той же файловой системе. Этот режим доступен только в определенных операционных системах и файловых системах.

Опция --jobs позволяет использовать несколько ядер ЦП для копирования/связывания файлов, а также для параллельного создания дампа и перезагрузки схем базы данных; хорошим местом для начала является максимальное количество ядер ЦП и табличных пространств. Этот вариант может значительно сократить время обновления сервера с несколькими базами данных, работающего на многопроцессорной машине.

Пользователям Windows необходимо войти в систему с учетной записью администратора, а затем запустить оболочку от имени пользователя postgres и указать правильный путь:

а затем запустите pg_upgrade с каталогами в кавычках, например:

После запуска pg_upgrade проверит совместимость двух кластеров, а затем выполнит обновление. Вы можете использовать pg_upgrade --check для выполнения только проверок, даже если старый сервер все еще работает. pg_upgrade --check также покажет любые ручные настройки, которые вам нужно будет сделать после обновления. Если вы собираетесь использовать режим ссылки или клонирования, вы должны использовать параметр --link или --clone с параметром --check, чтобы включить проверки для конкретного режима. pg_upgrade требует разрешения на запись в текущем каталоге.

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

Если при восстановлении схемы базы данных произойдет ошибка, pg_upgrade завершит работу, и вам придется вернуться к старому кластеру, как описано в шаге 17 ниже. Чтобы снова попробовать pg_upgrade, вам потребуется изменить старый кластер, чтобы восстановление схемы pg_upgrade прошло успешно. Если проблема связана с модулем contrib, вам может потребоваться удалить модуль contrib из старого кластера и установить его в новом кластере после обновления, при условии, что модуль не используется для хранения пользовательских данных.

Обновите резервные серверы потоковой репликации и доставки журналов

Если вы использовали режим ссылки и у вас есть резервные серверы потоковой репликации (см. раздел 26.2.5) или доставки журналов (см. раздел 26.2), вы можете выполнить следующие действия, чтобы быстро обновить их. Вы не будете запускать pg_upgrade на резервных серверах, а будете запускать rsync на основном. Пока не запускайте серверы.

Если вы не использовали режим ссылки, не используете или не хотите использовать rsync или хотите более простое решение, пропустите инструкции в этом разделе и просто заново создайте резервные серверы после завершения pg_upgrade. и запущен новый основной сервер.

Установите новые двоичные файлы PostgreSQL на резервные серверы

Убедитесь, что новые двоичные файлы и файлы поддержки установлены на всех резервных серверах.

Убедитесь, что новые резервные каталоги данных не существуют

Убедитесь, что новые резервные каталоги данных не существуют или пусты. Если была запущена initdb, удалите новые каталоги данных резервных серверов.

Установить общие объектные файлы расширений

Установите файлы общих объектов с тем же расширением на новых резервных серверах, которые вы установили в новом основном кластере.

Остановить резервные серверы

Если резервные серверы все еще работают, остановите их, следуя приведенным выше инструкциям.

Сохранить файлы конфигурации

Сохраните все файлы конфигурации из каталогов конфигурации старых резервных серверов, которые вам необходимо сохранить, например, postgresql.conf (и любые файлы, включенные в него), postgresql.auto.conf , pg_hba.conf , потому что они будут перезаписаны или удалены. на следующем шаге.

Запустить rsync

При использовании режима ссылки резервные серверы можно быстро обновить с помощью rsync . Для этого из каталога на первичном сервере, который находится над старым и новым каталогами кластера базы данных, запустите это на основном для каждого резервного сервера:

где old_cluster и new_cluster относятся к текущему каталогу на основном сервере, а remote_dir находится над старым и новым каталогами кластера на резервном. Структура каталогов в указанных каталогах на основном и резервном серверах должна совпадать. Обратитесь к странице руководства rsync для получения подробной информации об указании удаленного каталога, например,

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

Это делает запись ссылок, созданных режимом ссылок pg_upgrade, которые соединяют файлы в старом и новом кластерах на первичном сервере. Затем он находит соответствующие файлы в старом кластере резервного сервера и создает для них ссылки в новом кластере резервного сервера. Файлы, не связанные с основным, копируются с основного на резервный. (Обычно они небольшие.) Это обеспечивает быстрое обновление в режиме ожидания. К сожалению, rsync без необходимости копирует файлы, связанные с временными и незарегистрированными таблицами, поскольку эти файлы обычно не существуют на резервных серверах.

Если у вас есть табличные пространства, вам нужно будет запустить аналогичную команду rsync для каждого каталога табличного пространства, например:

Если вы переместили pg_wal за пределы каталогов данных, rsync также должен быть запущен в этих каталогах.

Настройка потоковой репликации и резервных серверов доставки журналов

Настройте серверы для доставки журналов. (Вам не нужно запускать pg_start_backup() и pg_stop_backup() или делать резервную копию файловой системы, поскольку резервные копии все еще синхронизированы с основной.)

Восстановить pg_hba.conf

Если вы изменили файл pg_hba.conf, восстановите исходные настройки. Также может потребоваться настроить другие файлы конфигурации в новом кластере, чтобы они соответствовали старому кластеру, например, postgresql.conf (и любые файлы, включенные в него), postgresql.auto.conf .

Запустить новый сервер

Теперь можно безопасно запустить новый сервер, а затем любые резервные серверы с rsync.

Обработка после обновления

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

Сценарии можно запускать в любом порядке и удалять после запуска.

Внимание

В целом небезопасно обращаться к таблицам, на которые есть ссылки в сценариях перестроения, до тех пор, пока сценарии перестроения не будут выполнены до конца; это может привести к неправильным результатам или снижению производительности. К таблицам, на которые нет ссылок в сценариях перестроения, можно получить немедленный доступ.

Статистика

Поскольку статистика оптимизатора не передается с помощью pg_upgrade , вам будет предложено запустить команду для повторного создания этой информации в конце обновления. Возможно, вам потребуется настроить параметры подключения в соответствии с вашим новым кластером.

Удалить старый кластер

Если вас устраивает обновление, вы можете удалить каталоги данных старого кластера, запустив сценарий, указанный после завершения pg_upgrade. (Автоматическое удаление невозможно, если у вас есть определенные пользователем табличные пространства внутри старого каталога данных.) Вы также можете удалить старые каталоги установки (например, bin , share ).

Возврат к старому кластеру

Если после запуска pg_upgrade вы хотите вернуться к старому кластеру, есть несколько вариантов:

Если использовался параметр --check, старый кластер оставался неизмененным; его можно перезапустить.

Если параметр --link не использовался, старый кластер оставался неизмененным; его можно перезапустить.

Если использовался параметр --link, файлы данных могли быть общими между старым и новым кластером:

Если pg_upgrade прервался до начала связывания, старый кластер не изменился; его можно перезапустить.

Если вы не запустили новый кластер, старый кластер не изменился, за исключением того, что при начале связывания к $PGDATA/global/pg_control добавлялся суффикс .old . Чтобы повторно использовать старый кластер, удалите суффикс .old из $PGDATA/global/pg_control ; затем вы можете перезапустить старый кластер.

Если вы запустили новый кластер, он выполнил запись в общие файлы, и использовать старый кластер небезопасно. В этом случае старый кластер необходимо будет восстановить из резервной копии.

Примечания

pg_upgrade создает различные рабочие файлы, такие как дампы схемы, в текущем рабочем каталоге. В целях безопасности убедитесь, что этот каталог не доступен ни для чтения, ни для записи другими пользователями.

pg_upgrade запускает недолговечных почтмейстеров в старом и новом каталогах данных. Временные файлы сокетов Unix для связи с этими почтмейстерами по умолчанию создаются в текущем рабочем каталоге. В некоторых ситуациях имя пути для текущего каталога может быть слишком длинным, чтобы быть допустимым именем сокета. В этом случае вы можете использовать опцию -s, чтобы поместить файлы сокетов в какой-либо каталог с более коротким именем пути. В целях безопасности убедитесь, что этот каталог не доступен ни для чтения, ни для записи другими пользователями. (Это не поддерживается в Windows.)

Все случаи сбоя, перестроения и переиндексации будут сообщены pg_upgrade, если они влияют на вашу установку; сценарии после обновления для перестроения таблиц и индексов будут сгенерированы автоматически. Если вы пытаетесь автоматизировать обновление многих кластеров, вы обнаружите, что кластеры с идентичными схемами баз данных требуют одних и тех же шагов после обновления для всех обновлений кластера; это связано с тем, что действия после обновления основаны на схемах базы данных, а не на пользовательских данных.

Для тестирования развертывания создайте копию старого кластера, состоящую только из схемы, вставьте фиктивные данные и обновите ее.

pg_upgrade не поддерживает обновление баз данных, содержащих столбцы таблиц, с использованием следующих системных типов данных, ссылающихся на reg* OID:

regcollation

regconfig

regdictionary

regnamespace

regoper

regoperator< /td>

regproc

regprocedure

( regclass , regrole и regtype можно обновить.)

Если вы обновляете кластер до PostgreSQL 9.2, в котором используется каталог только для файла конфигурации, вы должны указать реальное расположение каталога данных в pg_upgrade и передать расположение каталога конфигурации серверу, например, -d /real -data-directory -o '-D /configuration-directory' .

При использовании старого сервера до версии 9.1, который использует нестандартный каталог сокетов домена Unix или каталог по умолчанию, отличающийся от стандартного для нового кластера, установите PGHOST так, чтобы он указывал на расположение сокета старого сервера. (Это не относится к Windows.)

Если вы хотите использовать режим связывания и не хотите, чтобы ваш старый кластер изменялся при запуске нового кластера, рассмотрите возможность использования режима клонирования. Если это недоступно, сделайте копию старого кластера и обновите его в режиме ссылки. Чтобы сделать действительную копию старого кластера, используйте rsync для создания грязной копии старого кластера во время работы сервера, затем выключите старый сервер и снова запустите rsync --checksum, чтобы обновить копию с любыми изменениями, чтобы сделать ее последовательный. ( --checksum необходим, потому что rsync имеет гранулярность времени модификации файла только в одну секунду.) Возможно, вы захотите исключить некоторые файлы, например, postmaster.pid , как описано в Разделе 25.3.3.Если ваша файловая система поддерживает моментальные снимки файловой системы или копии файлов с копированием при записи, вы можете использовать их для создания резервной копии старого кластера и табличных пространств, хотя моментальный снимок и копии должны создаваться одновременно или при отключенном сервере базы данных.< /p>
См. также

Отправить исправление

Если вы обнаружите в документации что-то неверное, не соответствующее вашему опыту работы с конкретной функцией или требующее дополнительных пояснений, используйте эту форму, чтобы сообщить о проблеме с документацией.
<р>. Время шло. Размер системного каталога с базой данных PostgreSQL 1С достиг размера 35Gb. Размер базового dt-файла выгрузки 1С начинался где-то с 1,2Гб, детального фреймворка на его основе 16Гб. И как-то пора придумать что-то еще, чтобы обеспечить продуктивную работу пользователей в 1С.

Введение в базу данных PostgreSQL определялось выходной версией платформы «1С:Предприятие 8.1», в которой реализована поддержка базы данных PostgreSQL. Но все встречи с PostgreSQL проходили на резервном сервере (под управлением Linux), где при использовании тестового метода стоял вопрос о том, как использовать PostgreSQL в качестве базы данных для производственной базы данных 1С. В это время основной сервер (под управлением Linux) базы 1С работал в файлово-серверном режиме.

В свое время шел процесс перехода со старой системы на 1С. Ну это и понятно - нормативная справочная информация передавалась заранее, а в это время допускались текущие остатки и т.д. Количество пользователей (менее 10) и размер базового файла 1С (менее 3Гб), которым разрешено работать в файлово-серверном режиме.

Шло время. Пользователи по мере внедрения перенесены со старой системы на 1С. Количество пользователей росло. размер файла базы данных также увеличивается.

Настало время подключить к базе данных 1С удаленных пользователей в терминальном режиме (FreeNX). Количество лицензий пришлось снова увеличить. Ну что получилось поменять один ключ на ключ с большим количеством пользовательских лицензий и количество хостов для менеджера лицензий не увеличилось.

А дальше было самое скучное - размер базы 1С до неприличных размеров увеличился в PostgreSQL.

Все вместе - количество одновременных пользователей в базе данных 1С более 10 и размер файла 1С более 4Гб, очень негативно сказались на производительности пользователей 1С.

Настало время серьезно изучить возможность размещения в базе 1С базы данных PostgreSQL. Воспользовавшись знакомством с базой данных PostgreSQL, переход на SQL-версию размещения данных 1С прошел быстро и без потерь (сервер Linux).

ВАКУУМНЫЙ ПОЛНЫЙ ПОДРОБНЫЙ АНАЛИЗ;

РЕИНДЕКС БАЗЫ ДАННЫХ baza1c_81 FORCE;

Первый шаг в создании строкового файла cron:

0 17 * * 0 /var/lib/pgsql/backups/pgdump.sh, где 0-мин, 17-час, -день * * -месяц, 0 (день недели воскресенье);

Второй шаг — добавить строку cron в первую команду:

0 18 * * 0 /var/lib/pgsql/backups/vacuum.sh, с учетом 30-минутной работы pgdump.sh по созданию архива;

Включить команду Vacu.sh на работу от 6 до 8 часов.

Третий шаг для добавления строки cron, вторая команда:

30 марта * * 1 /var/lib/pgsql/backups/reindex.sh, учитывать время работы вакуум.sh;

Команда Reindex.sh выполняется не более 1 часа.

И каждый понедельник база данных готова к эффективной работе.

И время идет. Я думаю об использовании SSD-накопителей для местоположения WAL. А знакомство с вариантом работы в 64-битной системе было проведено.

PS Если вы начнете редактировать postgresql.conf, то после внесения изменений убедитесь в успешном запуске нового PostgreSQL c postgresql.conf. Также убедитесь, что вы создали успешную резервную копию, лучше всего восстановить базу данных на резервном сервере из резервной копии.

ПС. иногда расчет стоимости этот расчет начинает очень сильно думать о чем-то другом. Так вот, в этом случае можно попробовать отключить автоочистку файла конфигурации PostgreSQL, выполнить стоп-старт "Manager License-Server enterprise-PostgreSQL". После расчета стоимости конфигурационного файла вернуть все обратно, стоп-старт. Оценить время расчета и сделать вывод о необходимости повторения этих действий.

Скорее всего уже не PS, а дальше. Больная тема - остановите менеджер лицензий. И чаще всего эта остановочка применялась в пятницу вечером. Это когда пора запускать цех 1С и добавлять в отчет производство за смену, или на складе готовая продукция отгружается во вторую смену. В другие дни решить эту проблему помогает удаленный доступ, а в пятницу .

Несколько комментариев о 2011 году.

Они поставили SSD диски для WAL и Log PostgreSQL. Intel X25 - 2 шт. Но это дало, сказать сложно, последние замеры были на одной базе, а сейчас уже есть в PostgreSQL. И база растет.Вот бы отключить SSD и посмотреть, а вот на рабочем сервере не получится.

Проблема: При формировании некоторых отчетов 1С вылетают сообщения о вредоносных действиях. Решаем эту проблему обновлением видеодрайвера, либо в его свойствах отключаем аппаратное ускорение.

Проблема: Раз на 60 остается свободной лицензия 1-3, то пользователь 1С начинает тормозить свою работу. Решения пока не нашел.

Здравствуйте, что то не могу понять. Как подключить 1С с внешней базой данных postgresql
1с, версия клиента 8.3.11.3034
postgres 9.5.11-1, обе 32 битные.
Внешние источники данных создаем новый источник -> Данные - Добавить новую таблицу - Выбрать из списка - в списке драйверов выбираем PostgreSQL ODBC(UNICODE), в следствии чего вываливается ошибка.

Как исправить?
А вот тестовое подключение к БД

В какую сторону капать?

1 Как получить исходную ссылку на видео YouTube?

1 Как можно осуществить оплату в приложении через магазин приложений?

1 Как использовать переменную в команде?

2 Появление и исчезновение блока с классом — Native JS и DOM?

3 Как сделать правильный отступ в меню?

2 Не удается установить gulp-image ('gulp-imagemin), в чем может быть проблема?

1 Как вставить модуль SELECT2?

0 Какой клиент jabber для Android поддерживает XEP-0071 (форматирование html-сообщений XHTML-IM)?

Если проблема в работе со строкой подключения дизайнера, не используйте ее - вставьте строку вручную (или скопируйте из другой программы, в которой тестировались). Я внешний источник подключал много лет назад, как только они появились, и единственная проблема, с которой столкнулся, была связана со спецификой реализации ODBC на Linux (не ваш случай).

Еще, как вариант, можно заново скачать драйвер с сайта Постгреса и переустановить его (возможно, он просто как-то криво стал).

Работайте с помощью утилиты командной строки psql. Я был в коронном сценарии bash, который, таким образом, конектился к базе данных Postgres, выбирал выбранные данные и отправлял их вложением на электронную почту. Сработал довольно быстро. - прокомментировал Modesto28 7 июня 19 в 16:20

Дело в том, что конструктор даже Excel не может приконектиться.
Драйвер=;DBQ=C:\моиданные.xlsx;
Делать так, но не читает. Какой еще возможный способ получить данные через ODBC? - прокомментировал Charlie_Kub 7 июня 19 в 16:17

Читайте также:


Как открыть файл crx

Bnk-файл, чем открыть

Картинка занимает в памяти 3 Мб, определите ее информационный объем в килобайтах

Расширение МТС, чем открыть

Должен ли я удалить антивирус avast?