Довльно-таки часто приходится ставить и настраивать оракловые кластеры из нескольких нод с использованием внешних хранилищ. И конечно же, для заливки дампов нужны расшаренные папки, то есть папка в БД создается на уровне кластера, а значит она должна быть доступна со всех нод кластера. В таких случаях идеальным решением является использование кластерных файловых систем, и конечно же, одним из самых подходящих вариантов является использование кластерной файловой системы от Oracle — OCFS2.
Рубрика: Администрирование
В очередной раз ковыряясь в Oracle EM Grid Control, и попав в раздел администрирования хоста, увидел что для управления сервером надо поставить какой-то там YAST и скрипты. Ну и все-таки решил посмотреть какие же возможности тут есть. Поэтому если вам вдруг захотелось поадминить linux не из-под обычной консоли, а прямо из EM Grid Control, то вот небольшая инструкция как легко и просто это сделать. Может оно конечно уже и не актуально в свете выхода EM 12c, но вдруг кому-то пригодится.
После очередного апдейта безопасности MacOS X у меня в очередной раз слетел пых с ораклом. Во время шаманств при сборке пыха из сырцов, дабы скомпилить его с поддержкой iconv & oci8 столкнулся с вот такой проблемой:
kostik@KOsTIK: ~/Sources/php-5.3.8> make Makefile:148: *** missing separator. Stop.
Возникло это после ручной правки Makefile. Чего в обычной жизни делать не требуется. Но при сборке php под mac os x это неотъемлемый шаг. Если вы столкнулись с такой же проблемой, то знайте, что лечится она очень просто — надо использовать табы вместо пробелов там где требуются отступы. Так что просто внимательно следите за тем, что меняете. Меняйте только сами команды, а не отступы.
Что-то давно я ничего не писал в свой блог. А сегодня пятница, за окном льет как из ведра, работать уже лень… Подумал, что самое время что-то написать. Был у меня не очень давно разговор с товарищем на тему администрирования *nix-систем. Обсуждали мы вопрос того, какие темы/области/знания в разрезе *nix-систем хорошо бы знать, чтобы успешно устроиться на работу системным администратором. Я обещал составить небольшой список тем, которые надо освоить, чтобы можно было считать себя более-менее нормальным админом *nix (ну вероятнее всего linux).
Всем привет.
Столкнулся тут на днях со следующей проблемкой. Я работаю на Mac OS X, и поэтому все необходимое для разработки ПО у меня стоит на моем компе, тот же Апач, Пых (они вообще идут из коробки) ну и Майскуль.
Так вот, решил я для одного нового проекта заюзать MySQL Workbench. Это такая утилита, в которой можно построить UML-схему базы данных, все красиво разрисовать и потом слить эту структуру в конечную БД, так же есть Reverse Engineering. В общем, первое сливание текущей структуры из БД прошло гладко, а вот первая же заливка изменений в БД уже не получилась. Не смотря на то, что Workbench честно показывал изменения, после накатывания аптейта, он все равно продолжал считать, что все структуры разные. Дело в том, что я люблю называть таблицы красивыми именами, отражающими действительность, с заглавными буквами, разве что в дополнение к CamelCase стилю еще разделяю слова символом подчеркивания. Так вот после долгих изучений и изысканий обнаружилось, что установки по умолчанию в MySQL Server на Mac OS, не очень подходят для моего случая.
Как известно, в MySQL, база данных соответствует определенной директории на сервере, и каждая таблица хранится в виде файла (или нескольких в зависимости от движка). Поэтому регистро-чувствительность ОС играет немаловажную роль в обработке регистро-чувствительности при разрешении имен в базе данных. Это означает, что если ваш сервер на винде, то ему пофиг на регистр, в *nix-подобных системах же наоборот, регистр имеет значение, за исключением Mac OS, которая вроде как юникс, а файловая система там HFS+, которая не очень чувствительна к регистру.
В MySQL сервере есть 2 системных переменные которые имеют отношение к регистру имен, это lower_case_file_system и lower_case_table_names. Первая переменная отражает регистрочувствительность файловой системы, где расположено хранилище, оно может принимать всего два значения: OFF — фс чувствительная к регистру и ON — не чувствительна.
Вторая переменная, lower_case_table_names, отражает механизм, как происходит сравнение имен и способ их хранения. 0 означает, что имена сохраняются в том виде, в котором были заданы и сравнение чувствительно к регистру. При значении 1, имена таблиц хранятся в нижнем регистре и сравнение не чувствительно к регистру. В случае 2, имена хранятся как есть, но сравнение происходит в нижнем регистре.
По умолчанию эти переменные принимают вот такие значения на Mac OS X:
kostik@KOsTIK: ~> mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 6 Server version: 5.1.49 MySQL Community Server (GPL) mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 2 | +--------------------------+ 1 row in set (0.00 sec) mysql> select @@lower_case_file_system; +--------------------------+ | @@lower_case_file_system | +--------------------------+ | 1 | +--------------------------+ 1 row in set (0.00 sec)
И вот такие на *nix (проверил на Linux/FreeBSD)
kostik@linux: ~> mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 49773 Server version: 5.1.51 MySQL Community Server (GPL) by Remi mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ 1 row in set (0.00 sec) mysql> select @@lower_case_file_system; +--------------------------+ | @@lower_case_file_system | +--------------------------+ | 0 | +--------------------------+ 1 row in set (0.00 sec)
Если почитать описание этих переменных на сайте mysql (тут), то там написаны замечательные рекомендации по выставлению правильных параметров переменной lower_case_table_names. Если лень читать, то основная мысль: если вы используете InnoDB как основной движок, то поставьте везде этот параметр в 1.
Самый простой способ — это прописать эту переменную в файле конфигурации my.cnf в секцию [mysqld] и рестартануть Mysql сервер.
В общем-то я не открыл ничего нового, все это можно найти в офф. документации на сайте, статья: Identifier Case Sensitivity дает более развернутое описание этой ситуации. Рекомендую прочитать.
Вот и все!
И снова небольшая заметка о том, как поменять ключи SSH для сервера. Вообще эти ключи генерятся сами при первом обращении, но бывают случаи, когда может потребоваться сгенерить новые ключи, например когда ваш сервер — это виртуальная машина и вы его склонировали. Делается это в пару команд.
Небольшая заметка о том, как загрузить Линуск с Grub’ом в однопользовательском режиме. Потребность в этом бывает не часто, а точнее крайне редко, поэтому все время забываешь как же это делается. Вот чтобы не забыть, как говориться на заметку, ниже пара инструкций как это легко сделать.
Всем привет!
В данной заметке я расскажу о своем опыте клонирования сервера под управлением CentOS. Сама процедура в общем-то обычная и логичная, но есть некоторые моменты, про которые необходимо знать и помнить при переносе системы с одного железа на другое.
Возможно кому-то это конечно покажется очевидным и само собой разумеещимся, но вот я раньше этого не знал. Собственно о чем речь, спросите вы?
Постановка задачи:
Сделать автодополнение команд в баше после sudo, а так же возможность выполнения алиасов так же после sudo.
А в чем собственно проблема спросите вы? — Да ни в чем, если вам это не нужно, однако мне, живущему на Mac OS X, периодически приходится выполнять некоторые команды из под рута. А для этого как ни сложно догадаться, используется команда sudo. А поскольку Линуксоид я еще тот, то мне уже давным давно лень писать команды полностью, ведь есть TAB 🙂 Но по умолчанию автодополнение после написания sudo не работает.
Проблема номер два: это то что, после sudo так же не работают алиасы. Вот пример: у меня есть некоторое количество алиасов, среди них alias ll=’ls -l’. Вот что будет если вы попробуете выполнить:
> sudo ll
Password:
sudo: ll: command not found
В общем-то ничего сверх секретного я не скажу. Но дабы самому не забыть, да и вдруг кому-то пригодится.
Потребовалось мне обновить порты на одном из моих серверов на FreeBSD, дабы поставить ffmpeg версии > 0.5.
Сервер в общем-то локальный, для разработки, поэтому порты там последний раз обновлялись давным давно, когда ставилось изначально ПО.
Начал вспоминать как это делается. На ум первым делом пришла мысль о cvsup, которым я когда-то давно пользовался. Но! Но потом я вспомнил что есть уже давным давно более простой способ под названием portsnap. О нем собственно и речь.