TmpFS в FreeBSD
TmpFS - это быстрая и эффективная файловая система в ОЗУ, а не на ПЗУ, как прочие ФС. Предназначена для временного хранения файлов с оптимальным расходом памяти и скоростными характеристиками. Обычно используется при монтировании в каталог /tmp, в котором много постоянно меняющихся временных мелких файлов, поэтому может быть целесообразно размещать их в памяти.
TmpFS очень подобна RAM-диску, тем что данные находятся в оперативной памяти. При работе используется виртуальную память (virtual memory, VM), т.е. RAM и SWAP (при потребности подключается пространство подкачки).
Ранее я описывал как создать ФС в памяти с помощью драйвера md (Memory «disks») и хотелось бы упомянуть о нескольких отличиях MFS от TmpFS. Для MFS (Memory File System) нужно создание устройства памяти, т.е. блочного устройства, которое перед использованием нужно отформатировать для определенной файловой системы (например, UFS), которая обычно используется для применения на ПЗУ со своими опциями ориентированными на жесткие диски (например, настройки фрагментации, журналирования, дубликации и пр. операции с секторами/цилиндрами/головками). Поэтому при использовании md возникает дополнительная нагрузка на систему при работе с данными на этом блочном устройстве. TmpFS блочным устройством не является и ее можно использовать сразу после монтирования. MFS при монтировании резервирует и использует определенный объем ОЗУ, указанный при создании диска памяти (место под нее будет выделено из общего пула памяти и при необходимости может перемещаться в область подкачки), а TmpFS может динамически использовать свободную память. Далее…
pg_dumpall
Наименование
pg_dumpall — извлекает кластер баз данных PostgreSQL в скрипт
Синтаксис
pg_dumpall [connection-option...] [option...]
Описание
pg_dumpall это утилита для записи вывода («сброса») всех баз данных кластера PostgreSQL в один файл сценариев. Этот скрипт содержит SQL-команды, которые могут быть использованы как входные данные psql для восстановления баз данных. Это происходит путем вызова pg_dump для каждой базы данных в кластере. pg_dumpall также делает резервную копию глобальных объектов, которые являются общими для всех баз данных. (pg_dump не сохраняет эти объекты). На данных момент это включает информацию о базе данных пользователей и групп, пространствах таблиц и свойства, такие как права доступа к базам данных в общем.
Поскольку pg_dumpall читает таблицы из всех баз данных, то скорее всего вам придется подключаться в качестве суперпользователя базы данных для получения полного дампа. Также вам будут нужны права суперпользователя для выполнения сохраненного скрипта, чтобы была возможность добавлять пользователей и группы и создавать базы данных.
SQL-скрипт будет писаться в стандартный вывод. Используйте опцию [-f|file] или операторы командного интерпретатора для перенаправления его в файл. Далее…
pg_restore
Наименование
pg_restore — восстанавливает базу данных PostgreSQL из архивного файла созданного с помощью pg_dump
Синтаксис
pg_restore [connection-option...] [option...] [filename]
Описание
pg_restore – это утилита для восстановления базы данных PostgreSQL из архива созданного pg_dump-ом в одном из не-текстовых форматов. Она будет издавать команды необходимые для воссоздания состояния базы данных на то время, когда он был сохранен. Архивные файлы позволяют также pg_restore выбирать что восстановить или даже изменить прежний порядок пунктов восстановления. Архивные файлы предназначены для переноса через архитектуры.
pg_restore может работать в двух режимах. Если название базы данных задано, то pg_restore подключается к этой базе данных и восстанавливает содержимое архива напрямую в базу данных. В противном случае, скрипт, содержащий SQL-команды, необходимый для воссоздания базы данных создает и записывается в файл или на стандартный вывод. Этот скрипт вывода равноценный простому текстовому формату вывода pg_dump. Некоторые из опций управления выводом поэтому аналогичны опциям для pg_dump.
Очевидно, что pg_restore не может восстановить информацию, которая не присутствует в архивном файле. Для примера, если архив был сделан используя опцию «dump data as INSERT commands», то pg_restore не сможет загружать данные, используя команду COPY. Далее…
Использование Vim в повседневной работе
В данной заметке освещено несколько очень полезных возможностей редактора Vim для быстрой и удобной работы в нем.
«Вечная» отмена изменений
Начиная с версии 7.3. стала доступной так называемая «вечная» отмена изменений (undo-persistence). После включения данной функции все изменения, которые производились в документе, можно откатить даже после сохранения и закрытия этого файла. История изменений автоматически сохраняется в отдельном скрытом файле с расширением «.un~» в той же директории, где находится редактируемый документ. Либо в отдельной директории, которую можно задать в настройках; тогда название файла будет состоять из пути к редактируемому файлу, используя в качестве разделителя символ «%» вместо «/». Для включения всего этого пропишем в vimrc:
set undofile #включить "вечную" отмену изменений set undodir=~/.vim/undo/ #директория для файлов с историей изменений
Vim никогда не удаляет файлы с историей, поэтому в случае надобности это нужно делать самостоятельно, как и в случае с файлами резервных копий документа, если включена опция «set backup».
Режим «вклейки»
Не менее полезным будет познакомиться с так называемым режимом «вклейки», который включается командой «set paste». Это полезно использовать в терминале, когда нужно скопировать некоторый текст с другого окна и вставить в Vim во избежание непредвиденных эффектов. Vim с GUI (графическим интерфейсом) может различать вставляемый текст и обычно сделает это правильно без опции ‘paste’. Далее…
Проверка орфографии в Vim
Начиная с версии 7.0 в редакторе Vim появилась встроенная проверка орфографии, что часто бывает очень нужным и полезным. Например, если Vim является редактором писем в почтовом клиенте, да и вообще в работе с любым текстовым файлом.
По умолчанию при запуске Vim проверка орфографии выключена, т.е. установлено «setlocal nospell» или «setlocal spell spelllang=», что конечно же можно изменить, задав нужные настройки в файле конфигурации vimrc. Удобно будет создать всплывающее меню для переключения/выключения проверки орфографии конкретных языков с помощью возможности биндинга клавиш, например, используя и для управления выбором в vimrc прописываем:
set wildmenu set wcm= menu SpellLang.RU_EN :setlocal spell spelllang=ru,en menu SpellLang.off :setlocal nospell menu SpellLang.RU :setlocal spell spelllang=ru menu SpellLang.EN :setlocal spell spelllang=en map :emenu SpellLang.
Проверяемый язык задается аббревиатурой и указанием региона через нижнее подчеркивание (например, ru_ru, ru_yo, en_us, en_au), если регион не указан, то используются все (например, ru, en). Также можно одновременно указать несколько языков через запятую, для проверки многоязычного документа. Далее…
pg_dump
Наименование
pg_dump — извлекает базу данных PostgreSQL в скриптовый или архивный файл
Синтаксис
pg_dump [connection-option...] [option...] [dbname]
Описание
pg_dump - это утилита для резервного копирования базы данных PostgreSQL. Она создает непротиворечивую резервную копию базы даже если она используется в это время. pg_dump не блокирует другие пользовательские подключения к базе данных (чтения и записи).
Дампы могут быть записаны в формате скрипта или файла архива. Скриптовые дампы – это простые текстовые файлы, содержащие набор SQL команд, требуемых для восстановления базы данных на период времени, когда они были сохранены. Для восстановления с такого файла сценариев его содержимое перенаправляют в psql. Скриптовые файлы могут быть использованы для восстановления базы данных даже на других машинах и других архитектурах; с некоторой модификацией, даже на других SQL серверах управления базами данных.
Далее…
SQL дамп PostgreSQL
24.1. SQL дамп
Идея этого метода резервного копирования состоит в генерации текстового файла с SQL-командами, при передаче которого обратно на сервер возможно воссоздать базу данных в том же состоянии, в котором она была во время снятия дампа. PostgreSQL предоставляет для этой цели утилиту pg_dump. Основное использование этой команды следующее:
pg_dump dbname > outfile
Как видно, pg_dump пишет результат выполнения в стандартный вывод (прим. на экран). Ниже будет описано, как это может быть использовано.
pg_dump – это входящее в комплект поставки PostgreSQL клиентское приложение (тем не менее чрезвычайно функциональное). Это средство может выполнять процедуру резервного копирования с любого удаленного хоста, имея соответствующий доступ к базе данных. Но следует помнить, что pg_dump не работает без соответствующего доступа. На практике это должен быть доступ на чтение всех таблиц, дамп которых нужно сделать, поэтому почти всегда утилита выполняется от суперпользователя.
Для определения с каким сервером управления базами данных должен работать pg_dump используются опции командной строки -h host и -p port. По умолчанию в качестве host выступает сервер на котором запускается pg_dump или то, что задано переменной окружения PGHOST. Далее…
Настройка потоковой репликации в PostgreSQL 9
В версии PostgreSQL 8.3 и позже уже был доступен Warm Standby (теплый резерв), использующий PITR (Point-In-Time Recovery, появившийся в 8.0) также называемый «log shipping» (пересылка логов), когда транзакционные логи асинхронно копировались с ведущего узла и сохранялись на ведомом, а затем сразу проигрывались/применялись. Таким образом всегда была копия ведущего сервера при его останове, но пользоваться при Warm Standby ведомым сервером нельзя и он постоянно находился в режиме восстановления (in «recovery mode»).
Hot Standby (горячий резерв) идентичен Warm Standby, но ведомый сервер стал доступен для чтения (read-only), что является огромным преимуществом и дает возможность реализовать балансировку нагрузки запросов от приложения, при этом не оказывая никакой нагрузки на ведущий сервер. При данном способе транзакционные логи (по умолчанию размером 16MB) копируются через сеть в требуемое место (например, с помощью SFTP), а после этого происходит запись/обновление информации в базе на ведомом сервере. Конечно же, выполнение всех этих действий дает некоторые задержки актуализации данных на подчиненном сервере. Далее…
MFS, создание диска в памяти (RAM-диска)
Для реализации данной возможности в FreeBSD нужно чтобы драйвер виртуального диска md (device md # Memory «disks») был вкомпилен в ядро либо подгружен как модуль с помощью kldload geom_md. MFS (Memory File System, файловая система в оперативной памяти) — это частный случай использования драйвера md, как создание swap-а в файле. MFS позволяет монтировать директорию в оперативную память и работать с файлами там, как в обычной файловой системе, но при этом будет наблюдаться значительный прирост в скорости. Данную возможность полезно использовать при работе с большим колличеством часто обновляемых мелких файлов, к примеру, директория для временных файлов разнообразных демонов или скриптов.
Можно добавить запись об этом в /etc/fstab для создания при старте системы диска в памяти (также указав выделяемый размер оперативной памяти в разумных пределах, чтобы не получить в итоге нехватки ядерной памяти и паники ОС). Данные в этой директории, конечно же, после перезагрузки будут потеряны, поэтому это обязательно следует учесть, например, при пересборке мира через make данные в директории после перезагрузки системы будут утеряны и обновление не будет осуществлено. Далее…
Настройка/изменение порта в FreeBSD для установки программы определенной версии/ревизии
Случаются ситуации, что нужно установить/обновить приложение, версии которого в портах еще нет, либо откатить до определенного состояния разработки и нужный исходный код приложения доступен на каком-либо источнике.
Рассмотрим подобный случай на примере с поисковым полнотекстовым движком Sphinx. Для него существует два порта: содержащий официальный релиз /usr/ports/textproc/sphinxsearch (на данный момент версия 0.9.9) и /usr/ports/textproc/sphinxsearch-devel (бета-версию 1.10-beta). Исходные тексты, которые нужно будет скачать, доступны в SVN-репозитории с ревизиями на разные моменты исправления ошибок.
В подавляющем своем большинстве разработчиками какого-либо ПО для работы с исходниками (и не только) используется система управления версиями. Это, можно сказать, некая разновидность файлового сервера, но позволяет хранить версию дерева файлов (файлов и каталогов) за разные моменты времени, т. е. когда вносились какие-либо изменения (добавление, удаление, редактирование файлов) и история этих изменений. С таким хранилищем может работать любое количество человек, обладающих правом чтения и/или записи. В общем, системы управления версиями главным образом предназначены для записи и отслеживания изменений информации во времени. Очень распространенной системой управления версиями является Subversion (SVN), которая обладает рядом дополнительных полезных возможностей, по сравнению, к примеру с CVS. Далее…
Резервное копирование данных MongoDB
Существует несколько способов создания бекапа информации, находящейся в БД mongo. Наилучшим способом для регулярного использования, т. е. без простоя/блокирования/остановки сервиса, является использование утилиты mongodump. Она действует по принципу, как и утилита mysqldump в MySQL, делая бекап/дамп данных c работающего/используемого в данный момент сервера. Дамп в последующем может быть восстановлен с помощью утилиты mongorestore, которая также идет в комлекте поставки.
Лучше всего после внедрения сервиса, использующего mongodb, сразу настроить репликацию master-slave и в дальнейшем резервные копии снимать с подчиненного сервера, чтобы не нагружать главный сервер, работающий кроме чтения еще и на запись. Кроме того, slave-сервер будет очень полезен, если неожиданно «умрет» master-сервер, так как сделать его новым главным сервером достаточно простая процедура (подчиненный сервер выступает в качестве fileover-а).
Далее…
Использование cron и crontab
Cron – это программа, которая используется в unix-системах для выполнения заданий в определенное время. Задания могут запускаться как единоразово, так и переодически.
Служба пранирования заданий состоит из демона, который обычно называется crond и набора конфигурационных файлов – для каждого из пользователей в /var/spool/cron, общесистемного /etc/crontab и /etc/cron.d.
При загрузке системы, запускается демон cron и проверяет очередь заданий at и заданий пользователей в файлах crontab. При запуске, демон cron сначала проверяет каталог /var/spool/cron на наличие файлов crontab, которые имеют имена пользователей, соответствующие именам пользователей из /etc/passwd, также он проверяет /etc/crontab и наличие файлов в директории /etc/cron.d/. Найденные файлы загружаются в память, далее крон проверяет ежеминутно нужно ли запускать какое либо из заданий в данную минуту, кроме этого проверяется происходило ли обновления директории spool, cron.d или файла /etc/crontab.В случае обновлений, измененные файлы заново перечитываются. Таким образом, при обновлении файла крона нет необходимости производить его перезагрузку, все файлы будут считаны автоматически при последующей проверке. Далее…
Настройка ротации логов с помощью newsyslog
Ротация (rotate) — это замена текущего открытого, т. е. используемого приложением для записи в данный момент, лог-файла новым и переименование (возможно с архивированием) старого, который замещает еще более старый, существовавший до этого лог. Самый старый файл удаляется.
Помимо настройки самого логирования, которое обычно производиться с помощью syslogd в /etc/syslog.conf, важное значение имеет дальнейшее слежение и управление файлами журналов, которые хранят записи о произошедших событиях. Лог-файлы должны хранится за определенный период времени или содержать определенный размер данных. Так как это влияет на процент свободного места на диске и в частности на место в разделе с логами, за которым необходимо следить, поскольку полное его заполнение может привести к разнообразным проблемам. По современным меркам информация является самой ценной и ее потеря просто недопустима. Тем более если причину возникновения какой-либо проблемы можно выявить только используя журнальные файлы. Да и в конце концов, большой размер самого лог-файла приносит некоторые неудобства при работе с ним, т. к. иногда приходится разбивать его на более мелкие с помощью, к примеру, утилиты split.
Далее…
Мониторинг репликации в postgresql90-server
Встроенная репликация в PostgreSQL 9 реализована благодаря журналу опережающей записи (WAL – Write-Ahead Log) с помощью пересылки XLOG-ов с главного сервера на подчиненный. При настроенной репликации на мастере и слейве запускаются дополнительные процессы: «postgres: wal sender process» и «postgres: wal receiver process», соответственно.
Судить о времени отставания slave-сервера от master-сервера можно сопоставляя текущие позиции записей журнала WAL: текущей на мастере и принятой/примененной на слейве. Их можно получить используя pg_current_xlog_location и pg_last_xlog_receive_location/pg_last_xlog_replay_location, соответственно.
На главном сервере:
psql -c "SELECT pg_current_xlog_location()" -Upgsql postgres <!--more-->pg_current_xlog_location -------------------------- 0/B8C45908 (1 row)
mysqldump — бекап/дамп данных в Mysql
Mysqldump — это одна из утилит, входящих в пакет с клиентскими программами mysql-client. Используется для создания дампа одной или нескольких баз данных, отдельных таблиц или только их структуры с целью резервирования нужной информации и дальнейшего его восстановления в будущем. Дамп содержит в себе набор SQL-команд, которые выполняются последовательно при разворачивании.
При запуске mysqldump в качестве аргумента передается название базы данных либо ее определенные таблицы или перечисляются несколько баз с помощью ключа «–databases \ -B» либо все «–all-databases \ -A». Также можно указывать дополнительные опции, наиболее полезными из которых являются:
–quick \ -q – дамп непосредственно направляется на stdout (стандартный вывод — экран), не используя буфер;
–opt – соответствует заданию опций –quick –add-drop-table –add-locks –extended-insert –lock-tables, которые максимально ускоряют создание дампа;
Далее…