Сайты на ASP.NET и приложения на .NET есть смысл разрабатывать только с использованием MySQL и PostgreSQL-серверов. Я писал об этом много раз - Используем MySQL вместо MS SQL в проектах на ASP.NET и Используем PostgreSQL вместо MS SQL в проектах на NET и ASP.NET - иначе эти приложения становятся непероносимым мусором, привязанным к дорогущей микрософтовской платформе и владелец бизнеса и разработчики вступают в игру в кошки-мышки с Билом Гейтсом и мусорами. Разработчику и владельцу бизнеса хочется развиваться (в том числе в сторону увеличения функциональности SQL-сервера), но все более ли менее полезные возможности в MS SQL-сервере адски платные. Которые практически невозможно купить легально (по 57 тысяч долларов на процессор). И нет ни малейшей необходимости впадать в эту зависимость вообще и вообще даже вступать в эту игру с наперсточниками. Играть в эти бессмысленные игры с мусорами и Билом Гейтсом - это все равно что cходить 'на выборы' к Чурову - зачем вообще до такой степени унижать себя?

Итак, я поставил себе на свои Web-сервера новый Linux (Модернизация Web-сервера - долой платный софт и Hyper-V) и решил вынести на него несколько имеющихся MySQL и PostgreSQL баз. При такой операции могут встретиться несколько мелких проблем, которые могут отнять время. Ниже я покажу свою накатаную дорожку для обхода типичных проблем.

Начнем с MySQL. Для начала его надо поставить и поставить обычные средства доступа к нему.

Затем MySQL-сервер запускается и вводится рутовый пароль.

Затем проковыривается дырочка в фаерволе для доступа извне к машине к SQL-сервером.

Теперь уже можно запустить клиент управления сервером (которым мы будем восстанавливать бекапы и создавать юзеров).

Затем я создал трех новых юзеров, рутовый - которым можно заходить с любого хоста и пару нужных мне сейчас юзеров для двух баз, которые я собираюсь разместить на этом сервере. Рутовому юзеру дам все возможные права на все базы, а двум созданным юзерам я дам права на свои базы (и по чтению на главную базу).

Поскольку с хостинговой машины не видно моих других MySQL-серверов, я зашел с клиента локалного девелоперского кампутера и сделал дампы двух баз, которые я собираюсь восстановить на этом сервере.

Затем я пробросил на создаваемый сервер бекап, восстановил там первую базу и дал на нее права нужному юзеру.

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

Как оказалось, NoSQL-функции на Linux-машинах (в отличии от Win-машин) восстанавливаются только в режиме

   1:  SET GLOBAL log_bin_trust_function_creators = 1;

Кроме того, все имена функций регистрозависимы и DevArt мне изуродовал имена MySQL-функций, преобразовав их в UpperCase. Поэтому этот режим и эту функицю пришлось вручную поправить и откомпилировать в базу вручную.

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

Третья проблема восстановления оказалась с коллейтами. MySQL-клиент для сайтов .NET/MONO работает с коллейтом utf8_general_ci, а автоматическое восстановление базы у меня произошло с коллейтом utf8_unicode_ci. Непонятно, как это все работало, пока эта MySQL-база лежала на виндузовом сервере, но работало. При выносе MySQL-базы на юниксовый сервер такой номер не прошел. Коллейты пришлось выставить вручную в конфиге MySQL-сервера.

Кстати, здесь же в конфиге ставится одна из наиболее полезных команд для разработчика, которые я всегда сразу добавляю в конфиг - трассировка выполненных SQL-команд:

   1:  set global general_log_file = 'mysql.log';

   2:  set global general_log=on;

Но поскольку я разворачиваю эти базы уже боевую среду - в данном случае это не нужно. Со второй MySQL-базой, которую я хотел вынести на этот сервер, я поступил иначе - я настроил VPN, чтобы увидеть с нового SQL-сервера старый. И тупо приконнектился с нового сервера в старый - и напрямую забекапил и восстановил базу.

После этого я назначил права второму юзеру на вторую базу и удалил права у своего привелегированного юзера, которого я создавал для этих манипуляций.

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

В одном из моих проектов на постгресе (терминальной сети) мне пришлось поставть постгрес раз наверное тридцать. Я ставил его из дистрибутивов EnterpriseDB и остался разочарован этим дистрибутивом. В каких-то случаях он срабатывает отлично, но в каких-то совершенно не работает. Кроме того, инсталятор работает как коммерческое ПО, проверяя логин/пароль регистрации дистрибутива в EnterpriseDB. Поэтому я решил опробовать OpenSCG-дистирибутив.

В целом он на мой Linux встал и запустился отлично - я вообще ничего для этого не делал, даже конфиг ему не правил, только разрешил коннектится к нему извне и проковырял для него дырочку в фаерволе. Однако при попытке загрузить в него базу обнаружилась проблема, этот дистрибутив стал в локализации en-EN.UTF8, у него была явная проблема с русской локализацией, которой тупо у него не было в кодировке UTF8. А все что я хотел загрузить в этот сервер было у меня именно в локализации Russain_Russian.UTF8.

Весь кайф автоматической инсталяции оказался испорчен - директорию для базы и конфиги пришлось создавать вручную. Хотя конечно в этом ничего сложного нет, для создания структуры базы предназначена утилита initdb. Надо только правильно указать локализацию, а не так как я сначала - потому что кодировка по умолчанию для русской локализации не UTF-8, а ISO-8859-5. После правльно проинициализированной базы, правильного назначения прав на директорию с базой и правки конфигов - мой PostgreSQL 9.0 отлично стартанул и работал уже без проблем.

Теперь пару слов о клиенте для доступа к PostgreSQL. Их вообще-то существуют десятки, но я привык к PgAdmin 3 (в дистрибутиве EnterpriseDB он всегда присутствует). Строго говоря, на боевом хостинге наверное можно обойтись и без PgAdmin, но я поставил его себе (тоже с сайта PostgreSQL.org).

С этой софтиной у меня возникли две проблемы - во первых у нее неверно прописаны зависимости в дистрибутиве и она не подтянула автоматически из инета библиотеку libpng12.so.0

А во-вторых наиболее востребованный админский функционал backup/restore почему-то не включен в состав готового пакета PgAdmin3 и эти пункты отсутсвуют в контекстном меню базы и в меню инструментов PgAdmin.

Конечно набирать вручную все многочисленные параметры pg_dump - не большое удовольствие, но если один раз понять эти параметры - дальше все будет проще. Альтернатива - скомпилировать PgAdmin самому из исходников с включением AdminPack, но поскольку к этому серверу у меня есть вход ПГ-админом со многих других кампутеров, я этим заморачиваться не стал, а просто сделал backup/restore нужной мне базы вручную.

Как видите, в развертывании на хостинге MySQL и PostgreSQL нет ничего сложного - несколько простых навыков (на уровне солдатской смекалки) позволяют довольно просто обходится без MS SQL.

Comments ( )