#1
Отправлено 25 Апрель 2012 - 13:49
В организации становится всё больше станций с установленными агентами и наконец "созрел" на переход с внутренней базы на внешнюю. Не совсем понятно каким руководством можно пользоваться для данного мероприятия, я бы даже сказал операции
Нашел две статьи на ВиКи:
http://wiki.drweb.com/index.php/PostgreSQL_как_внешняя_СУБД_для_ES
http://wiki.drweb.com/index.php/Смена_типа_СУБД_Dr.Web®_Enterprise_Suite
Плюс в руководстве администратора есть раздел посвященный смене СУБД (как я понял тоже самое что и во второй ссылке)
Каким руководством пользоваться? Как проверить что работает именно внешняя СУБД и что оно нормально работает? Может быть есть еще какие-то ньансы?
#2
Отправлено 25 Апрель 2012 - 14:42
1. Какую СУБД планируете использовать в качестве внешней?
2. Что именно из конкретики непонятно?
1. Проверить очень просто - после перехода ваша внутренняя БД (по умолчанию это файл dbinternal.dbs в каталоге var больше не будет обновлять свою дату модификации, ну и ессно, в файле конфигурации drwcsd.conf будет указан не он, впрочем, это можно увидеть и через Конфигурацию сервера веб-интерфейса управления). И, как апогей - в логе drwcsd.log вы увидите, что используется при загрузке сервера в качестве СУБД.
#3
Отправлено 25 Апрель 2012 - 14:54
2) Две инструкции, какую использовать? В одной из них указана конкретная версия Postgre 8.3.8 , т.е. если следовать ей, то более новые версии не подходят что-ли?
Про проверку СУБД всё понял, очень доходчиво, спасибо
#4
Отправлено 25 Апрель 2012 - 15:13
2. Первая ссылка о как бы изначальном использовании PostgreSQL в качестве СУБД, вторая ссылка непосредственно о смене.
От себя могу резюмировать общий алгоритм таким образом:
1. Устанавливаете СУБД.
2. Создаете там (в СУБД) пользователя и БД для ES - например при помоши батника create_drwebes_pgsql.cmd:
rem BEGIN OF FILE
rem Create user
psql --dbname postgres --username postgres --command "CREATE ROLE drwcs WITH NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN ENCRYPTED PASSWORD 'drwcs';"
rem Create tablespace
rem mkdir C:\DATA
mkdir c:\data\pg_drwebes
psql --dbname postgres --username postgres --command "CREATE TABLESPACE drwebes_ts OWNER postgres LOCATION 'C:/data/pg_drwebes';"
rem Create database
psql --dbname postgres --username postgres --command "CREATE DATABASE drwebes OWNER postgres ENCODING 'UTF8' TABLESPACE drwebes_ts;"
rem Create schema
psql --dbname drwebes --username postgres --command "CREATE SCHEMA drwcs AUTHORIZATION drwcs;"
rem Create alter role
psql --dbname postgres --username postgres --command "ALTER ROLE drwcs SET search_path to '$user', 'public';"
rem END OF FILE
Результат: будет создана БД drwebes и пользователь drwcs с паролем drwcs в качестве владельца БД
Обратите внимание, что в данном скрипте предполагается, что БД будет расположена в каталоге c:\data, что не является обязательным и остается на ваш выбор, а также используется кодировка UTF-8 для БД, что обязательно.
3. Устанавливаете на ПК, где ES-сервер, рекомендованный драйвер ODBC,
4. Там же, используя вкладку System DSN Настроек ODBC, добавляете новое подключение, выбираете UNICODE вариант Postgresql драйвера и настраиваете ODBC подключение в соответствии с мануалом. Test connection должен пройти успешно.
5. Далее по http://wiki.drweb.com/index.php/Смена_типа_СУБД_Dr.Web®_Enterprise_Suite
#5
Отправлено 25 Апрель 2012 - 15:18
Версия ES 6.0.3 (ОС действительно Windows)
Огромное спасибо за подробную инструкцию, буду пробовать
#6
Отправлено 25 Апрель 2012 - 15:24
#7
Отправлено 25 Апрель 2012 - 16:12
1) Установил PostgreSQL
2) Создал пустую базу и пользователя
3) Установил драйвер ODBC
4) Добавил новое подключение и проверил его.
Как я понял, если просто подключить новую базу, то заново нужно будет назначать группы клиентским ПК и настраивать ES-сервер? Или не так понял?
P.S. Просто ежедневно работают более 250 пользователей и заново их подключать будет не очень удобно
Сообщение было изменено VladimirN: 25 Апрель 2012 - 16:13
#8
Отправлено 25 Апрель 2012 - 16:18
п. 5 моего эссе.
#9
Отправлено 26 Апрель 2012 - 08:17
Вроде всё получилось. Есть пара ньансов которые могут пригодиться тому кто пойдет таким же путём :
1) Если создавать базу через cmd (bat) файл, то запускать его надо из папки PostgreSQL\{версия}\bin или добавить строку смены каталога перез запуском основных команд.
2) Если создавать базу через cmd (bat) файл, то на папку c:\data\pg_drwebes надо дать права пользователю postgres на запись (Через безопасность папки)
3) Теоретически можно добавить в конец файла строчку pause чтобы контролировать правильность выполнения команд.
4) В момент указания в интерфейсе ES данных о новой базе (логин, пароль и т.п.) есть пункт "Имя источника данных, DSN", я честно говоря не сразу понял что это за штука и писал туда имя базы , но это было неправильно. Правильно писать имя которое выводится при добавлении нового источника данных ODBC, в моём случае это было PostgreSQL35W
Еще раз спасибо Foxes за помощь.
Сообщение было изменено VladimirN: 26 Апрель 2012 - 08:17
#10
Отправлено 26 Апрель 2012 - 09:00
#11
Отправлено 26 Апрель 2012 - 09:47
#12
Отправлено 26 Апрель 2012 - 12:15
Основная цель была перевести именно на внешнюю БД, поскольку с внутренней уже начали возникать проблемы. Выбирал изначально из PostgreSQL и SQL CE, почему именно выбрал Postgre сейчас уже не скажу -- не помню , но наверное в случае если когда-нибудь понадобиться перевести ОС на базу Линукса, то это должно пройти проще.
Foxes,
Хочется в это верить
Вопрос не совсем по теме, но может подскажите: правильно ли я понял, что внешняя база (в отличии от внутренней) не "бэкапится" средствами ES? Т.е. будет правильно настроить резервное копирование средствами самого PostgreSQL?
#13
Отправлено 26 Апрель 2012 - 12:37
Foxes, опа.. .НУ давайте расскажите, какие проблемы с MS SQL express возникнут у пользователя??
Сообщение было изменено durashki: 26 Апрель 2012 - 12:39
#14
Отправлено 26 Апрель 2012 - 12:59
Вопрос не совсем по теме, но может подскажите: правильно ли я понял, что внешняя база (в отличии от внутренней) не "бэкапится" средствами ES? Т.е. будет правильно настроить резервное копирование средствами самого PostgreSQL?
Бэкапится, но вы можете и средствами постгреса это делать - на ваш выбор.
.НУ давайте расскажите, какие проблемы с MS SQL express возникнут у пользователя??
"Тут ведь как... Можете взлететь, а можете не взлететь..." (с) Могут возникнуть, а могут и нет. Статистика показывает, что почему-то проблем больше с MS SQL и Oracle-ом, чем с PostgreSQL. Конечно же, непреодолимых фатальных проблем нет, иначе бы поддержку MS SQL выпилили бы целиком.
#15
Отправлено 26 Апрель 2012 - 13:58
Сообщение было изменено durashki: 26 Апрель 2012 - 13:59
#16
Отправлено 26 Апрель 2012 - 15:17
Ответ прост - это проблемы внутренней реализации самого ПО - какие он использует БД и для чего, лишь бы удовлетворял требованиям по производительности, надежности, функциональности, безопасности и т.д.
Если СУБД будет приходить вместе с ESS, устанавливаться и настраиваться средствами инсталлятора ESS.
Если ESS будет обеспечивать, через тот же веб-интерфейс управление/обслуживание используемой СУБД - разве администратора будет беспокоить - какая СУБД используется?
Все четко бекапится и работает как часики на двух серверах в кластере, чего не умеет делать тот же PostgreSQL
Что из перечисленого не умеет делать pgsql? Бэкапиться, работать как часики? Умеет.
В отношении обеспечения отказоустойчивости у pgsql есть свои пути, кроме как использования кластеров от Microsoft.
Например в 9.1 реализовано Synchronous replication http://wiki.postgresql.org/wiki/Synchronous_replication
В качестве примера высоконагруженной работы с распределениям по нодам можно привести heroku.com
#17
Отправлено 26 Апрель 2012 - 16:34
#18
Отправлено 26 Апрель 2012 - 18:10
Никого не колышет какой встраиваемой базой пользуется приложение.знаете, что тот же Firefox использует для своих нужд sqlite?
#19
Отправлено 27 Апрель 2012 - 09:50
Никого не колышет какой встраиваемой базой пользуется приложение.
А в чем отличия, Василий, для администратора? Между встраиваемой и не встраиваемой?
Обслуживания, в случае больших объемов и нагрузки, требуют и та и другая. Бэкапа тоже. Возможностей по настройке и функционалу у встраиваемой меньше.
На мой взгляд, заблуждение в том, что внешняя (условно ее так назовем) СУБД, считается какой-то отдельной сущностью. Отдельной от основного ПО. В общем случае, так может быть, но не обязательно. Другой вопрос, что, скажем интегрировать управление и обслуживание такой СУБД, как Оракл в ЕС - это сложно и проблемно. Майкрософтовские БД проприетарные и некроссплатформенные. Есть конечно много чудных проприетарных и кроссплатформенных, например, IBM DB2, но это удорожает стоимость.
На сегодняшний день, по совокупности качеств, как мне думается, оптимальным вариантом для ЕС являются PostgreSQL или Firebird (Он, правда, не поддерживается).
Предлагаю рассматривать используемую СУБД, как библиотеку или модуль, в составе ЕС, при условии, что все обслуживание будет доступно средствами самого ЕС Сейчас это, конечно не так, именно поэтому поддерживается некая линейка СУБД, задачи по обслуживанию которых, на плечах администратора, а это значит, что каждый выбирает по своим возможностям и знаниям. В этих условиях, конечно же, абсолютно равноправный выбор как постгреса, так и мс скл, так и оракла. Вот почему durashki тоже прав
#20
Отправлено 27 Апрель 2012 - 11:00
Also tagged with one or more of these keywords: СУБД, DrWeb Enterprise
Русские форумы →
Dr.Web Enterprise Suite →
ESS для UNIX+СУБД в ALDАвтор: npc_irs , 03 дек 2020 postgresql, СУБД, ALD и еще 5… |
|
|
||
Русские форумы →
Dr.Web Enterprise Suite →
ES10: Ошибка при смене СУБД с внутренней на MS SQL ServerАвтор: navoiy88 , 02 июл 2015 СУБД, SQL Server |
|
|
Читают тему: 1
0 пользователей, 1 гостей, 0 скрытых