Archive for the ‘Базы данных’ Category



18
апреля
0

Отказоустойчивость Mysql master-master на основе Keepalived



Keepalived позволяет выполнять балансировку трафика и повышает отказоустойчивость за счет виртуального IP на основе протокола VRRP. Для нашей конфигурации мы не будем использовать балансировку трафика, а только настроем виртуальный IP для двух Mysql серверов, работающих в режиме master-master.

Имеем следующие исходные данные:

10.1.11.11 — виртуальный ip, на который маршрутизируются mysql соединения
10.1.11.10 — mysql сервер test1
10.1.11.9 — mysql сервер test2 Click to continue…

22
февраля
0

Создание rpm пакета из исходников



Способ установки пакетов из исходников при помощи make install имеет несколько недостатков, а именно это позднее мешает обновлениям, засоряет систему, усложняет контроль версий ПО и т.д. В многих дистрибутивах линукс для управления ПО используется RPM (Red Hat Package Manager), который позволяет устанавливать, удалять и обновлять программное обеспечение.

В этой статье мы рассмотрим способ сборки rpm пакетов из исходников. Сборку пакета будем производить в дистрибутиве RHEL6, а в качестве исходников использовать keepalived-1.2.15.tar.gz Click to continue…

11
сентября
3

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] или операторы командного интерпретатора для перенаправления его в файл. Click to continue…

1
августа
1

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. Click to continue…

8
июля
1

pg_dump



Наименование
pg_dump — извлекает базу данных PostgreSQL в скриптовый или архивный файл

Синтаксис
pg_dump [connection-option…] [option…] [dbname]

Описание
pg_dump — это утилита для резервного копирования базы данных PostgreSQL. Она создает непротиворечивую резервную копию базы даже если она используется в это время. pg_dump не блокирует другие пользовательские подключения к базе данных (чтения и записи).
Дампы могут быть записаны в формате скрипта или файла архива. Скриптовые дампы — это простые текстовые файлы, содержащие набор SQL команд, требуемых для восстановления базы данных на период времени, когда они были сохранены. Для восстановления с такого файла сценариев его содержимое перенаправляют в psql. Скриптовые файлы могут быть использованы для восстановления базы данных даже на других машинах и других архитектурах; с некоторой модификацией, даже на других SQL серверах управления базами данных.
Click to continue…

26
июня
0

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. Click to continue…

6
июня
12

Настройка потоковой репликации в 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), а после этого происходит запись/обновление информации в базе на ведомом сервере. Конечно же, выполнение всех этих действий дает некоторые задержки актуализации данных на подчиненном сервере. Click to continue…

20
апреля
4

Резервное копирование данных MongoDB



Существует несколько способов создания бекапа информации, находящейся в БД mongo. Наилучшим способом для регулярного использования, т. е. без простоя/блокирования/остановки сервиса, является использование утилиты mongodump. Она действует по принципу, как и утилита mysqldump в MySQL, делая бекап/дамп данных c работающего/используемого в данный момент сервера. Дамп в последующем может быть восстановлен с помощью утилиты mongorestore, которая также идет в комлекте поставки.

Лучше всего после внедрения сервиса, использующего mongodb, сразу настроить репликацию master-slave и в дальнейшем резервные копии снимать с подчиненного сервера, чтобы не нагружать главный сервер, работающий кроме чтения еще и на запись. Кроме того, slave-сервер будет очень полезен, если неожиданно «умрет» master-сервер, так как сделать его новым главным сервером достаточно простая процедура (подчиненный сервер выступает в качестве failover-а).
Click to continue…

5
марта
2

Мониторинг репликации в 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) 

Click to continue…

10
февраля
2

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, которые максимально ускоряют создание дампа;
Click to continue…

19
декабря
0

Master-Slave репликация MongoDB



Как было упомянуто в предыдущей статье, MongoDB поддерживает репликацию данных. Чтобы получить отказоустойчивость системы должен быть как минимум один реплицируемый сервер, который примет тяжелое бремя master-а, в случае скоропостижной потери онного. Такое переделегирование обязанностей требует вмешательства системного администратора, если используется схема репликации master-slave, которая будет рассмотрена ниже.

При асинхронной master-slave репликации в каждый конкретный момент времени только один сервер работает на запись (master), а остальные на чтение (slave). Для реализации рассмотрим пример из двух серверов, но не забываем, что слейвов может быть много.

После установки и запуска mongod на FreeBSD с параметрами по умолчанию демон будет «слушать» соединения на порту 27017: Click to continue…

11
декабря
4

MongoDB: настройка, управление и использование сервиса, бекап данных



Mongo — это специальная объектно-ориентированная база данных или хранилище структурированных данных, что-то среднее между привычной реляционной СУБД и key-value хранилищем. Хранение данных происходит в виде JSON-подобных документов (document-based). Без особых трудностей mongod может работать с базой, насчитывающей несколько миллионов объектов. Имеется поддержка динамических запросов, индексов, профилирование запросов, репликация и поддержка fail-over.
MongoDB целесообразно использовать для хранения постоянно изменяющихся данных для сайта,т.е. гибкой работы с информацией в реальном времени, а также, отлично справляется с задачами кэширования.

Комплект поставки и запуск

После установки программы на FreeBSD имеем следующие исполняемые файлы:

cat /var/db/pkg/mongodb-1.6.2/+CONTENTS | grep "^bin/"
bin/mongo
bin/mongod
bin/mongodump
bin/mongoexport
bin/mongofiles
bin/mongoimport
bin/mongorestore
bin/mongos
bin/mongosniff
bin/mongostat 

Click to continue…