Недочет алгоритма в том, что backup выполняется вслепую без проведения теста на вероятность его восстановления. В настоящей статье мы предлагаем автоматически восстанавливать backup на резервном сервере с поддержанием рабочей резервной копии сайта.

Предлагаем следующий алгоритм действий: Каждый день в 5 утра, cron на сервере www запускает скрипт backup.pl, тот, что выполняет следующий строй действий: Создает дамп базы и архив каталога htdocs. Копирует дамп и архив на backup-сервер. Запускает на backup-сервере скрипт store backup.pl, который выполняет следующие дествия: Удаляет каталог htdocs и пересоздает пустую базу данных. Разархивирует архив файлов и восстанавливает базу данных из дампа. Добавляет информацию в. Делает иные действия, требуемые для работоспособности перенесенного сайта.

Создает каталог с именем, совпадающим с текущей датой и в него переносит новые backup-файлы. В результате живого бэкапа, на резервном сервере неизменно будет работоспособная версия сайта.

Заказчик сможет обследовать, что backup на самом деле существует и работает и это придаст ему хладнокровие и уверенность в качестве услуг. По датам сообщений на сайте будет видно, что резервная копия сделана в эти дни в 5 утра. Образец В качестве примера рассмотрим бэкап сайта webew.ru. На каждом сервере настроен apache, на первом на адрес webew.ru, на втором на адрес backup.webew.ru.

На каждом сервере есть пользователь webew, база данных webew, а корневой каталог сайта - каталог htdocs в домашнем каталоге пользователя webew. Помимо того, для удобства поместим имя и пароль для доступа к базе данных в файл. Start backup. 2... 2 webew backup. Скрипт store backup.pl на сервере backup: ! AuthType Basic AuthName webew AuthUserFile home webew. Файл. Если вы опасаетесь взлома основного сервера, то процедуру разрешено направить: скрипт.

В таком случае злоумышленник, получивший доступ к основному серверу не сможет принять ssh-доступ к резервному. Заключение Живой бэкап позволяет заказчику быть уверенным, что резервная копия в действительности есть. Кроме живого бэкапа, не забывайте беречь копии проектов на локальной машине и на сменных физических носителях. Все права на данную статью принадлежат порталу webew.ru.

Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции. Резервный сервер находится в "теплом" состоянии. Т.е. MySQL и Apache не запущены. При необходимости запускаем Apache и MySQL и получаем рабочую копию сервера. Попутно решается задача, когда бекапить надобно кучу сайтов. Копирование файлов базы при том, что первостепенный сервер работает, с большущий вероятностью приведет к битым таблицам.

Оптимальный вариант: rsync + репликация базы данных, но в этом случае испытать работоспособность сайта-копии будет нельзя, так как это нарушит репликацию. Если бинарики таблиц напрямую копировать будут траблы. Ибо это только усложняет задачу, причем, не совершенно обоснованно. С дампом может быть ряд неприятностей.

Неприятное следствие в том, что когда дамп требуется возродить, у него могут внезапно вскрыться недостатки, которые никого не беспокоили до этого. В настоящее время, пускай я заказчик. Я знаю, что есть дамп. Но позволительно ли его будет воссоздать или нет? Нелегко произнести глядя на дамп, не тестируя его. Предложенный подход автоматизирует тестирование.

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

Предположим, на моем VDS у меня есть план projectname.ru и я решил произвести его резервную копию на backup.projectname.ru на том же VDS. Всё великолепно работает, но в единственный не хороший день на сервере сыпется хард и я теряю как основную версию сайта, так и бекап. Нет смысла живой backup действовать на том же сервере. В частности, рассмотренный в примере сайт webew переносится на backup.webew.ru, размещенный на отдельном георгафически удаленном VDS.

Как отметил paulus, лучше эти скритпы прямо строчить на bash.

По материалам http://webew.ru/articles/1462.webew

Нередко инфа представляет большую ценность и вероятность её потери нужно слить к минимуму. Немудрёный образец. Вы 30 мин набивали важное сообщение, а следом невзначай нажали ссылку или закрыли вкладку и информация оказалась потеряна. К примеру, не возбраняется беречь послание в черновик или пользоваться автосохранением.

Ещё, с помощью JavaScript, позволительно дополнительно перестраховаться и выдавать пользователю диалог при попытке закрытия страницы. В реализации некоторых браузеров у объекта window есть событие beforeunload. Оно генерируется при попытке выгрузки текущего окна. Его стандартный обработчик и показывает тот самый диалог. К сожалению, не получится сменить это диалоговое оконце собственным, при всем при том, с помощью свойства returnValue разрешается изменить контент во второй строке предупреждения.

Делается это так: window. Value "Вы же ничего не сохранили!" Событие beforeunload генерируется в Gecko и IE. В Опере и Сафари описанная фича не работает. При некоторых вариантах закрытия окна браузер может опустить диалог. В частности, при нажатии Ctrl+W в IE7.

Дополнение от veb и pepelsbey : В Safari это уже предусмотрено. После этого набития текста в любое поле, оконный проем браузера без этого предупреждения уже не прикрыть. Все права на данную статью принадлежат порталу webew.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции.

Ещё вопросительный мотив к строчке evt evt window. Как будто как нет. У меня не получилось.

По материалам http://webew.ru/articles/1024.webew

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

Механизмы блокировок позволяют избежать ситуаций одновременного доступа к данным. MySQL от имени одного из клиентов накладывает блокировку на установленный ресурс, при этом другие клиенты ждут освобождения блокировки. Построчная блокировка достигается посредством усложнения структуры хранилища: в MyISAM архитектура файла с данными представляет собой простое перечисление строк таблицы, тогда как хранилище InnoDB структурировано и поддерживает мультиверсионность данных.

Вследствие этого, InnoDB выигрывает в приложениях, в которых происходит многопоточное трансформирование данных в одну и ту же таблицу, несмотря на необходимые потери на обслуживание больше сложного хранилища. Блокировки бывают двух видов: на чтение и на запись. Если А хочет вписать данные, то другие клиенты не должны ни впитывать текст ни сочинять эти данные покуда А не закончит(write lock).

Блокировка может быть наложена прямо или неявно. Если клиент не назначает блокировку явным образом, MySQL сервер неявно устанавливает потребный тип блокировки на миг выполнения выражения или транзакции. К примеру, в случае выполнения оператора SELECT сервер установит READ LOCK, а в случае UPDATE - WRITE LOCK.

Зачастую возникает надобность выполнения нескольких запросов кряду без вмешательства других клиентов в это пора. Неявная блоктровка не подходит для этих целей, так как устанавливается только на час выполнения одного запроса. В этом случае клиент может очевидно определить, а опосля отменить блокировку с помощью выражений LOCK TABLES и UNLOCK TABLES. Явной блокировка завсегда блокирует всю таблицу, независимо от механизма хранения.

Применение явных блокировок В случае явной блокировки не возбраняется принять выигрыш производительности за счет однократного назначения блокировки и задержки записи обновленных индексов до на момент блокировки. Для ранних версий, необходимо установливать блокировку на все таблицы, входящие в представление.

Разрыв соединения илм завершение сессии автоматически снимает все установленные в рамках данной сессии блокировки. Блокировка таблиц может быть нарушена транзакцией и напротив. START TRANSACTION неявным образом осуществляет UNLOCK TABLES и наоборот LOCK TABLES откатывает незаконченную транзакцию. Для установки блокировки требуется обладать привилегии LOCK TABLES и SELECT на каждую блокируемую таблицу.

Если одна из требуемых таблиц заблокирована в рамках иной сессии, то оператор блокировки не выполнится в то время как все таблицы не освободятся. Типы блокировок: READ - блокирует таблицу для чтения. Все клиенты могут обретать данные в то же время, но никто не может их изменять, более того тот клиент, тот, что установил блокировку. WRITE - блокирует таблицу для записи.

Только клиент установивший блокировку может получать и изменять данные. Применимо только к таблицам MyISAM, которые не имеют дыр, образованных в результате изменения или удаления строк. В этом случае, добавление новых данных производится в финал таблицы. Если таблица имеет дыры, то их разрешается устранить, используя оператор OPTIMIZE TABLE. LOW PRIORITY WRITE - блокирует таблицу для записи, но во период ожидания блокировки пропускает тех клиентов, которые стоят в очереди на получения блокировки типа READ.

Примечание: системная переменная concurrent inserts определяет вероятность добавления данных в конец таблицы MyISAM, заблокированной для чтения. По умолчанию, эта переменная равна 1, что означает возможность добавления данных при отсутствии в таблице дыр. Таким образом, в случае неявной блокировки, для таблиц MyISAM устанавливается READ LOCAL, а не READ.

Значимость concurrent inserts равное 0 запрещает добавление данных параллельно с чтением, а равное 2 разрешает вставку данных в конец таблицы даже при наличии в таблице дыр. Заключение В статье рассмотрены только основные вопросы использования блокировок в MySQL. Не освещены транзакции, уровни изоляции, advisory lock и др. Напишите в комментариях какие из вопросов вам интересны. Все права на данную статью принадлежат порталу webew.ru.

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

По материалам http://webew.ru/articles/1383.webew