Обзор средств синхронизации баз данных MySQL. OLTP- и OLAP-системы: сравнительная характеристика
Друзья, всем привет! Рад всех вас видеть у себя в гостях 😉 Сегодня я расскажу, как синхронизировать базы данных WordPress. А так же о том, какие таблицы в базе наиболее важные и как с ними работать.
Эту тему я освещаю не просто так. Как вы помните, я рассказывал о том, как . Очень удобная возможность при разработке сайтов.
Так вот, после доработки сайта, его нужно вернуть на хостинг. И с этим, вообще, нет никаких проблем. В том случае, если во время вашей работы на локальном сервере, сайт, расположенный, в интернете не обновлялся. Но такие случаи бывают крайне редко.
А вот если вы регулярно обновляли сайт и при этом работали, как я, над его дизайном у себя на компьютере, то возникает определенная трудность. В вашей локальной базе будет новый дизайн, но не будет новых статей и комментариев.
И вот тут-то и нужна синхронизация базы данных. Именно так можно объединить в базе данных и новый дизайн, и новые записи. А уже после, без проблем, перенести готовый сайт обратно на хостинг.
И это лишь один пример, но вы уже и сами поняли, что умелое обращение с базой данных открывает перед вами новые возможности в работе над сайтом.
Структура базы данных WordPress
Прежде чем приступить к синхронизации нужно разобраться, что синхронизировать. База данных Вордпресс состоит из множества таблиц, в которых хранятся данные о пользователях, статьях, категориях, тегах, плагинах, комментариях, системных настройках и многое другое.
По большому счёту досконально разбираться во всех таблицах необязательно. Достаточно знать, в каких таблицах находится информация о статьях, комментариях и так далее. Именно эти таблицы имеют ключевое значение при синхронизации.
Итак, рассмотрим ключевые таблицы в базе данных WordPress.
wp_options – содержит все настройки сайта;
wp_posts – все статьи и записи на сайте;
wp_postmeta – вспомогательные данные о статьях и записях на сайте;
wp_comments – комментарии;
wp_commentmeta – вспомогательная информация о комментариях;
wp_term_relationships – связи статей и записей с категориями и тегами;
wp_terms – связи категорий (рубрик) со ссылками;
wp_term_taxonomy – связи категорий, тегов, ссылок;
wp_usermeta – информация обо всех зарегистрированных пользователях;
wp_users – информация об администраторе.
Многие другие таблицы в базе данных создаются всевозможными плагинами, виджетами, и прочими такими инструментами. В основном в этих таблицах собрана системная информация, её можно использовать с пользой. Так, посмотрев внимательно эти таблицы, вы можете узнать по какому ключевому запросу пришёл посетитель, на какую страницу, был ли это первый визит или повторный, и даже с какого браузера и операционной системы.
Вот теперь, когда общее представление о базе данных WordPress у вас сложилось, можно приступать к цели нашего урока – синхронизации баз данных.
Подготовка к процессу синхронизации
Прежде чем приступить к работе с базой данных, — обязательно сделайте резервную копию. Так как если вы сделаете, что-то не так. То сможете всё восстановить из копии.
Так, вы и процесс поймёте, и сможете создать нужную базу данных на своём компьютере и перенести на хостинг уже готовую БД.
Самое главное не забудьте про резервную копию.
Сравнение баз данных в phpMyAdmin
Этот шаг необязательный, но лучше, если вы будете знать, как, подручными средствами, сравнить базы данных. Меня эти знания частенько выручают.
Использовать для этого будем утилиту phpMyAdmin, которая доступна и на хостинге и на локальном сервере.
В качестве сравнения будем использовать базу данных на локальном сервере, которую я использовал в работе над . И базу данных, которая используется у меня на моём блоге.
Для сравнения возьмём одну цифру – количество статей. Так как для таких сайтов, как мой, – это самое ценное. Ну и комментарии, конечно. К тому же эти цифры всегда у вас на виду.
Анализируем тестовый сайт и базу данных:
Для начала посмотрим на количество статей. Сделать это можно в административной панели Вордпресс. Достаточно открыть консоль.
Как видно, на скриншоте, статей на тестовом сайте – 136.
После обновления темы оформления, я успел написать ещё пару статей. И сейчас их уже 138.
Количество статей должно соответствовать количеству записей в таблице wp_posts . Но, если открыть эту таблицу, то записей вы увидите гораздо больше.
Как видите на скриншоте – всего записей 2,245. И среди них и статьи и отдельные записи. А ещё это куча черновиков и прочих записей о картинках и так далее.
Поэтому сразу определить количество статей нереально. Для этого потребуется сделать небольшой запрос с параметрами сортировки.
Открываете базу данных – таблицу wp_posts – переходите на закладку SQL – вводите запрос:
SELECT * FROM `wp_posts` WHERE `post_status` = "publish" AND `post_type` = "post"
Этот запрос говорить о том, что в таблице wp_posts нужно выбрать все записи (* ), где статус – опубликовано (publish ) и это статья (post ).
В итоге получаем 136 записей. Вот теперь эта цифра соответствует количеству статей.
Точно так же сверяется и другая база данных. В моём случае – реальная база с моего блога.
Эти знания помогут вам не потерять ничего важного. И проверить после синхронизации, всё ли прошло успешно.
В качестве досадного примера расскажу небольшую историю. Один мой знакомый, однажды переезжал с одного хостинга на другой. Делал всё по инструкции, техподдержка ему помогла. Но, через какое-то время он заметил, что на его сайте не хватает двух статей. Когда он попросил меня разобраться, в чём может быть проблема, я провёл сверку, и выяснилось, что в новой базе нет двух записей, которые есть в старой базе данных. Скорей всего, когда он переносил базу данных, то что-то сделал не так и потерял эти две статьи. В результате пришлось немного поколдовать и вернуть эти две статьи на их законное место.
Вот почему важно знать, как провести сверку. И убедиться, что после синхронизации, все ваши записи успешно перенесены из одной базы в другую.
Синхронизация баз данных WordPress
Все действия будем делать на локальном сервере. А после готовую базу данных можно импортировать на хостинг.
Шаг 1. Создание двух пустых баз данных
Если возникает вопрос почему две базы, то объясняю, — это нужно для того, чтобы не трогать рабочие базы данных и показать пример с чистого листа.
Первым делом запускаете Денвер и в браузере набираете localhost/tools/ , а далее жмёте на ссылке phpmyadmin .
Шаг 2. Импортируем данные в базу
Итак, я сделал резервные копии баз данных. Одну с тестового сайта, другую с моего блога в интернете. Они понадобятся для импорта содержимого во вновь созданные базы. А далее будут страховкой.
У вас должно быть тоже две базы, которые вы будете синхронизировать.
Теперь нужно импортировать данные из резервных копий в новые базы данных. Для этого выбираете новую базу – откройте закладку «Импорт» — выбираете «файл резервной копии» — нажимаете кнопку «Ок» .
Шаг 3. Синхронизация баз данных
Вообще, есть возможность просто копировать нужные таблицы из одной базы в другую. Но мы рассмотрим непосредственно процесс синхронизации. Как полной так и частичной (в виде отдельных таблиц).
Для этого нужно перейти на главную страницу phpMyAdmin и выбрать раздел «Синхронизировать» .
Теперь в качестве источника определяем базу данных с блога в интернете (она более свежая), а в качестве целевой базы – базу с тестового сайта. Наша задача скопировать новые статьи, комментарии и теги в базу данных тестового сайта.
После того как пройдёт сравнение. На выбор будет предложено синхронизировать отдельные таблицы, в которых есть изменения, или провести полную синхронизацию.
Если вы хотите синхронизировать отдельные таблицы, то необходимо нажать на буквы S или D . Эти буковки станут серыми, а в окошке ниже вы увидите добавленные таблицы на синхронизацию. После чего вы можете синхронизировать эти таблицы, нажав на кнопку «Применить выбранные изменения» .
В нашем случае подходит именно этот способ, так как нам нужно синхронизировать только статьи, комментарии и метаданные.
Для синхронизации баз данных полностью, ничего отмечать не нужно. Достаточно нажать на кнопку «Синхронизировать базы данных» .
Вот, и всё. На этом процесс синхронизации окончен. Можно проверять результат. Для наглядного примера, я сменил базу данных на локальном сайте. Если кто забыл, делается это в файле wp-config.php. И теперь можно сравнить количество статей, записей и комментариев. Правда, комментариев на блоге стало немного больше, пока я писал статью.
Статистика по тестовому блогу:
Статистика по рабочему блогу:
Ну и напоследок напомню, что синхронизировать базу данных это ещё половина дела. К базе данных должны прилагаться и файлы, задействованные в работе сайта. К примеру, если не скопировать скриншоты, сопровождающие статью, то статья будет без них с пустыми местами.
А теперь советую посмотреть видеоурок, в котором весь процесс синхронизации баз данных я показываю шаг за шагом.
Сегодня на этом всё. Всем желаю хорошего настроения. До встречи в новых материалах. И конечно же, жду ваших комментариев 😉 А полученные знания пригодятся вам при .
Подписывайтесь на новые статьи!
Текст был обработан Грищенко В.И.
Начало
Рано или поздно с этим сталкиваются все. Ну если не все, то многие. Сталкиваются в той или иной степени - кто-то в простейшем варианте, кто-то в сложном. Иногда находятся стандартные средства, иногда обнаруживается, что задачу можно упростить до частного случая. Но иногда проблема встает именно так, что стандартные средства не находятся или не устраивают, а задача синхронизации баз данных не упрощается до частного случая...
В свое время эта задача встала и передо мной. Некоторые СУБД имеют встроенные средства синхронизации (этот процесс еще иногда называют репликацией, а иногда эти понятия различают). Но во-первых, мне нужно было синхронизировать базы под управлением InterBase, а во-вторых, даже те средства сторонних производителей, которые для этой СУБД существуют, меня не устраивали. Мне был необходим такой механизм синхронизации, который не предусматривает постоянного наблюдения администраторами на всех БД - программа писалась в расчете на маленькие организации. InterBase для этого подходил идеально - легкий, надежный (уж точно надежнее локальных БД!), практически не требующий администрирования при не слишком сильной загрузке. Да где же взять такой репликатор? Да еще чтобы был простой как пробка - запустил - отработало. Да еще чтобы в программу вставить работу! Да еще чтобы мог синхронизировать базы под Win и под Unix!
Два дня поисков подходящих средств в Internet ни к чему не привели. Много рекламы, мало информации, бешеные цены и, что уже просто надоело, "очень удобные средства для администратора с помощью которых очень легко исправлять коллизии". Ну нет у меня администратора, который мог бы следить за каждой синхронизацией (проходящей пару раз в день) и исправлять коллизии! Что же делать?
Ладно, попытка - не пытка, я решил поискать что-нибудь по алгоритмам, используемым при репликации баз данных.
НИЧЕГО.
Абсолютно ничего!
Если я плохо искал и кто-то мне покажет интересные в этом плане и свободно доступные материалы, я буду рад! Но по-видимому это khow-how фирм-производителей или до сих пор не разработано каких-то общеизвестных алгоритмов на эту тему. Лезу в Дейта. Ничего. Так, рассуждения на тему распределенных БД, но того, что мне нужно, нет.
Так или иначе, но, помолясь, я решил обмозговать это все сами посмотреть, что получится. Обмозговал. Помучился. Написал. Исправил. Исправил. Еще раз исправил. Заработало. Сглючило. Исправил - перестало глючить. Пока работает. Мне нравится. Работает! Проблемы, конечно, есть. И некоторые весьма приличные. Но... но все таки оно работает!
Так что я решил рассказать, кому интересно, то что я думал и что делал.
Варианты, терминология
Все термины самопальные, так что не обижайтесь, если что-то покажется глупым. :)
Синхронизация - процесс при котором базы данных приводятся в идентичное состояние. Если кто-то придумает определение получше я его выслушаю.
Сначала расклассифицируем синхронизацию по направленности и времени проведения.
Если данные могут меняться только в одной из баз данных, а в остальных они не меняются пользователями, то синхронизацию на таких базах назовем однонаправленной или односторонней. Если же данные могут быть добавлены/изменены/удалены пользователями системы в нескольких базах системы - то это будет двунаправленная(двусторонняя) синхронизация.
Если синхронизация должна проводиться немедленно после внесения изменений в БД, то такую синхронизацию назовем синхронизацией в реальном времени . А если изменения из одних баз должны вноситься в другие базы ПОЗЖЕ, по команде/событию/etc - то это будет отложенная синхронизация .
Разделим теперь отложенную синхронизацию еще на два подкласса. Если для синхронизации необходимо соединение с обоими базами данных иона проводится путем анализа расхождений в этих базах, то назовем ее синхронизацией по текущему состоянию . А если синхронизация проводится по журналу - списку вносимых изменений в базы - то так и назовем - синхронизацией по журналу . Обе эти разновидности встречаются в коммерческих разработках. Забегая вперед, скажу, что я реализовывал синхронизацию по текущему состоянию.
Далее. Если при проведении синхронизации изменения могут выявляться и производиться отдельными полями записей, то это синхронизация по полям . Если же "единицей" проведения синхронизации является запись - то это синхронизация по записям .
Это вроде бы все понятно интуитивно, но хочется строгости и не хочется размолвок из-за различий в терминологии.
Теперь одно очень важное определение, о существовании которого, оказывается некоторые разработчики, впервые встретившиеся с нашей проблемой не знакомы. Коллизия - это некоторая неопределенность, иногда ошибка, возникающая при синхронизации и обусловленная тем, что алгоритмы синхронизации не идеальны, да и сама задача часто ставит трудноразрешимые проблемы. Или даже вообще не разрешимые в рамках принятой схемы синхронизации. На различные примеры коллизий мы посмотрим попозже.
Отсекаем лишнее
Итак, я упомянул несколько вариантов синхронизации и теперь от "лишних" следует избавиться. :) Мы не будем рассматривать синхронизацию в реальном времени это все-таки довольно экзотическая задача. Мы рассмотрим одностороннюю синхронизацию, но очень коротко - это довольно простая задача, ее можно решить без коллизий (по крайней мере, мне так кажется, хотя я могу и ошибаться). Ясно, что односторонняя синхронизация легко реализуется любым методом двухсторонней (по журналу или по текущему состоянию), но без множества проблем, присущих двусторонней синхронизации. И конечно, основная наша цель - это двусторонняя отложенная синхронизация.
Идентификация записей
Для того, чтобы правильно проводить синхронизацию данных любым способом, очевидно, необходима однозначная идентификация записей во всей системе (по крайней мере в рамках одной таблицы). Если для кого-то это покажется неочевидным, скажите, я напишу подробнее.
Для унификации желательно, чтобы в каждой таблице, включенной в процесс синхронизации, был суррогатный первичный ключ (ID) - обычно INTEGER. Впрочем, чаще всего так и есть. Как же мы можем обеспечить уникальную идентификацию записей.
- Можно ввести в каждую таблицу дополнительное поле - номер БД, в которой эта запись была создана впервые (DBID). При этом, очевидно, ID уже не будет являться первичным ключом, вместо этого первичным ключом будет пара (DBID, ID). Следует заметить, что из-за этого данное решение не слишком привлекательно
- Можно сделать первичным ключом строку специального формата, например XXXX-YYYY-ZZZZZZZZ, где XXXX - это идентификатор базы данных, где запись была создана впервые, YYYY - идентификатор таблицы, ZZZZZZZZ - идентификатор записи внутри конкретной таблицы конкретной БД. Такое решение является хорошо масштабируемым, позволяет "запихать" в ID много дополнительной информации, но у него тоже есть минусы. Во-первых, некоторая избыточность информации. Во-вторых, более сложный механизм генерации таких ID. И еще, неплохо было бы ограничить возможные значения ID данным форматом. Это тоже заботы.
- На мой взгляд, для InterBase лучшим вариантом является следующий - ID для всех таблиц генерируется обычным триггером, выбирающим значения из генератора. При этом начальное значение генератора различно для разных БД, за счет чего обеспечится уникальность ID по всем БД. Данный подход характерен для InterBase. Применение его для других СУБД может быть ограничено невозможностью задать начальное значение для счетчика автоинкрементных полей.
Ясно, что я выбрал третий вариант. :) Остается еще один вопрос - тип данных для ID. Ясно, что есть для ID использовать INT64 (NUMERIC(18)), то вопрос с доступным диапазоном номеров не встает - диапазон огромен. Но к сожалению, есть некоторые проблемы, мешающие это сделать. Дело в том, что до сих пор в Delphi поддержка полей Int64 несколько хромает. Это связано как с недоработками компонент доступа к данным (IBX, FIBPlus), так и с изначальным отсутствием в классе TField поддержки полей Int64.
В то же время, если мы внимательно посмотрим на диапазон INTEGER, то обнаружим, что при
- использовании только положительных значений
- использовании единственного генератора на все таблицы БД
- ежедневном создании в системе 10000 записей
нам хватит диапазона INTEGER на 27 лет работы системы из 21 БД. При этом начальные значения генераторов разных БД будут определяться как DBID * 100000000. Для большинства систем это вполне нормальные показатели.
Коллизии
В этом разделе мы рассмотрим возможные варианты изменений в базе данных и отметим, в каких случаях вероятно возникновение коллизий. Разделим все вносимые изменения на два класса - изменения, вносимые в одиночные независимые таблицы и вносимые в таблицы, связанные отношениями FOREIGN KEY.
Кроме того, коллизии могут быть вызваны за счет работы триггеров и ограничений прикладного характера.
Изменения в одиночных таблицах
В таблицу добавляется новая запись
После проведения синхронизации эта запись должна появиться в остальных БД. Первой причиной для коллизий при этом изменении может быть конфликт первичных ключей, но эта проблема легко разрешима (см. выше). Так что если в любых БД будет добавлена куча записей все они должны без проблем продублироваться в остальных.
Ну, может еще стоит отметить, что если сразу после синхронизации эти записи были удалены из исходной БД, то при следующей синхронизации они НЕ должны восстановиться. :) Впрочем, это скорее, относится к следующему подразделу:
Причиной коллизии могут стать ограничения типа UNIQUE. Поясняю. Пусть есть 2 БД: A и B. На таблицу (Table1) наложено ограничение UNIQUE(Field1). Пусть в начальный момент времени в обоих базах НЕТ записей, у которых Field1 = Value1. Добавим такую запись сначала в A, а затем в B. Ошибок не возникает - ограничение UNIQUE не нарушено. Теперь пытаемся синхронизировать эти БД. По логике вещей, мы должны создать в каждой БД по 1й записи. Но не можем, так как это вызовет нарушение ограничения. Конечно, при условии того, что данные были введены верно и модель построена правильно, это должны быть ОДИНАКОВЫЕ (по предметным полям) записи, они должны описывать одну сущность. Но нам от этого не легче - коллизия возникла и ее надо разрешать. Разрешить ее можно удалением записи из одной базы и повторным проведением синхронизации.
Эта является замечательным примером того, что коллизия может возникнуть безотносительно конкретной реализации механизма синхронизации. Она возникает принципиально из-за распределенности системы и отложенности синхронизации.
В общем, подобные "логические" коллизии практически неотслеживаемы. И это очень печально.
Из таблицы удаляется запись
После проведения синхронизации эта запись должна удалиться, если она там есть, из других БД. Опять-таки, возможны "логические" коллизии - допустим, триггер проверяет наличие хотя бы одной записи, у которой Field1 = Value1.Сначала в обоих БД было по две такие записи. В обоих базах удалим по одной записи. При этом ошибок не будет, так как остается вторая. Но если мы удалили в разных базах разные записи, то после синхронизации возникнет ошибка, так как в итоге в базах не окажется ни одной записи Field1 = Value1. В случае такого рода ограничений, опять-таки, по-видимому, без администратора, хорошо знакомого со структурой БД и способного исправить такие коллизии ничего не выйдет:(.
В таблице изменяются некоторые поля записи
После проведения синхронизации в других базах эта запись должна измениться аналогичным образом.
Первая и очень вероятная коллизия заключается в одновременном изменении записи в разных БД. Эта коллизия имеет два варианта - если изменяются одни и те же поля и если изменяются разные поля.
В первом случае, очевидно, один вариант изменения неверен - ведь описываемая сущность имеет вполне конкретное значение данного параметра. Приняв за правду более позднее изменение или более "главную" БД, мы легко можем разрешить вопрос.
А второй случай, при синхронизации на уровне записей может вызвать серьезнейшую проблему - потерю введенной информации. Привожу пример. Вышеупомянутый Иванов И.И. опять побежал в вышеупомянутые учереждения. В первое он побежал и сказал там, то он теперь инвалид второй группы, что оператор и занес в БД. Прибежав в тот же день во второе учереждение он сказал, что у него родилась тройня (или просто второе учереждение - это родильный дом и там все сами узнали, а Иванов бегал только в одно учереждение). Там изменили поле "кол-во детей". Внимание! Если синхронизация производится целыми записями, то в зависимости от времени изменений или от "главности" баз мы потеряем ту или иную введенную информацию, если только умный администратор не увидит подробнейшее описание случившегося и не исправит эту ситуацию руками. Я полагаю, это ясно.
Так что мы видим, что синхронизация на уровне записей не только приводит к перекачке неизмененных полей, но и может служить источником очень неприятных ошибок. В то же время, к сожалению, для реализации синхронизации н уровне полей необходимо гораздо больше служебной информации и гораздо более сложные структуры данных. К тому же, реализация синхронизации по полям может упереться в возможности СУБД - необходимо определять список измененных полей и зачастую это тоже нетривиальная задача.
Изменения в связанных таблицах
Будем рассматривать коллизии при синхронизации таблиц TableA и TableB. TableB имеет внешний ключ (FOREIGN KEY), ссылающийся на TableA. Тогда записи таблицы A будут родительскими, а соответствующие записи таблицы B - дочерними.
- В базе А создается дочерняя запись, в базе В удаляется родительская
- В базе А дочерняя запись передается от родительской записи 1 к родительской записи 2, в базе В удаляется родительская запись 2
Создается новая родительская запись или новая дочерняя запись к существующей родительской
Создается новая родительская запись и дочерние к ней
И родительская и дочерние записи должны появиться в других БД. Здесь становится важным порядок создания записей в результирующей БД - сначала должна создаваться родительская запись, затем дочерние. Впрочем, в тех СУБД, в которых ограничения ссылочной целостности проверяются только при подтверждении транзакции, это не обязательно. Но даже в них нельзя посоздавать все новые родительские записи, подтвердить транзакцию, а затем посоздавать новые дочерние записи.
Удаляется дочерняя запись
Никаких особенностей нет, дополнительных проблем из-за связанности таблиц не возникает.
Удаляется родительская запись и дочерние
В результирующей БД должны удалиться сначала дочерние записи, затем родительская.
Циклы FOREIGN KEY
Влияние триггеров
Синхронизация по журналу - общие принципы
Это наиболее часто применяемый метод. Все действия, производимые в БД (создания, удаления и изменения записей) сохраняются в некотором журнале - обычно это отдельная таблица или набор таблиц в самой БД.
Заполнение журнала производится триггерами, которые записывают в журнал информацию, достаточную для повторного выполнения произведенного действия. Понятно, что в случае удаления записи достаточно сохранить идентификатор таблицы и значение первичного ключа удаленной записи, а для изменения или создания записи нужно также сохранять значения полей. Обычно также сохраняется отметка времени, когда было произведено изменение.
Для синхронизации двух БД на каждой из них повторяют все действия, произведенные в другой БД, извлекая их по очереди из журнала. Отсюда следует одно из преимуществ синхронизации по журналу - нет необходимости в установлении соединения с БД - журнал, выведенный в отдельный файл можно передать по "floppynet" :) Необходимо только тщательно отмечать, какие записи журнала еще не передавались. Эта проблема усложняется при наличии нескольких синхронизируемых БД - нужно запоминать, какая последняя запись журнала была передана в каждую из БД.
Понятно, что после успешного применения журнала к другой БД журнал можно урезать. Но тем не менее, журнал занимает много места - в лучшем случае дублирует новые и измененые записи.
Если одна и та же запись изменялась несколько раз подряд, то можно либо хранить все промежуточные изменения, либо "склеить" эти изменения в одно. Это снизит размер журнала, но может привести к лишним коллизиям.
Для синхронизации по журналу характерно увеличение хранимых данных пропорционально количеству изменений в цикле синхронизации, и скорость синхронизации также пропорциональна количеству изменений в цикле синхронизации.
Следует также упомянуть, что на базе журнала можно построить службу отката состояния БД практически на любой момент (если только соответствующие данные не были удалены из журнала).
Синхронизация по журналу реализуется достаточно просто, но очевидно, что коллизии при этом неизбежны. Для иллюстрации этого предлагаю вам следующую аналогию. Представьте себе, что у вас есть 2 комнаты, в которых расположены ящики. У вас есть робот, который можно запрограммировать на перемещение ящиков. В начальный момент ящики в комнате расположены одинаково. Вы подаете роботу команды и он перемещает ящики. Ваш напарник подает команды другому роботу во второй комнате. После этого вы приказываете роботам поменяться местами и повторить все действия, начиная с начального момента. Очевидно, что это может привести к неприятностям - в первой комнате робот передвигал ящик №5, но во второй комнате его не оказалось на месте, в первой он подвинул ящик №54 в угол, но во второй угол оказался занят.
При этом следует отметить, что удачное приложение журнала 2 в БД 1 еще не означает, что без ошибок отработает журнал 1 в БД 2.
Преимущества
- Нет необходимости в установке соединения
- Можно вернуть БД на любой момент в прошлом
- Сравнительная простота реализации
- Высокая скорость синхронизации - пропорциональна кол-ву изменений за цикл
Недостатки
- Большие объемы хранимых данных - пропорциональны кол-ву изменений за цикл
- Коллизии практически неизбежны
Синхронизация по текущему состоянию - общие принципы
Синхронизация по текущему состоянию в различных продуктах мне встречалась гораздо реже, чем синхронизация по журналу. Но, мне кажется, из этого нельзя делать вывод об ее применимости. Известно, что в разных задачах лучше применять более подходящие методы.
Итак, синхронизация по текущему состоянию всегда выполняется с установлением соединения, так что применить этот метод без наличия какого-либо канала связи между серверами нельзя.
Процесс, производящий синхронизацию, устанавливает соединение с обоими БД (если баз больше двух, то синхронизация выполняется попарно - например, "цепочкой" или "звездой") и пробегает по всем синхронизируемым таблицам в поисках различий. Здесь мы видим первый существенный недостаток метода - скорость синхронизации пропорциональна полному количеству записей в БД. Напомню, что для синхронизации по журналу скорость была пропорциональна кол-ву измененных данных.
Когда различия находятся, то управляющий процесс эти различия убирает, приводя обе БД к идентичному виду. При этом приходится принимать решение - какая из БД содержит более верные данные по текущей обрабатываемой записи - следует ли удалить запись из базы 1 или наоборот, создать такую же в базе Б, где она пока отсутствует.
Однако, в отличие от синхронизации по журналу, когда при приложении журнала отсутствует какая-либо дополнительная информация, в данном случае управляющий процесс может выдавать вспомогательные запросы в обе БД для того, чтобы максимально хорошо разрешить все коллизии - например, узнать, есть ли в других таблицах записи, ссылающиеся на данную. Таким образом, задав определенные правила, можно автоматически разрешать довольно большую часть коллизий.
Если вспомнить аналогию с роботами, ящиками и комнатами, то в данном случае робот будет заглядывать в обе комнаты и, если увидит, что ящик №15 стоит в разных местах, то, приняв какое-то из расположений за верное, постарается в другой комнате поставить его в то же место. При этом, если его место занято, то возможен дополнительный анализ - а каким ящиком занято? а почему не занято в первой комнате?
Нетрудно заметить, что подобный метод в принципе более правилен - вместо того, чтобы в новых условиях тупо повторять действия из другой БД, возможен анализ различий и максимально безопасное их устранение.
Для проведения синхронизации по состоянию обычно для каждой записи БД вводятся одно или несколько дополнительных полей, по которым управляющий процесс сможет определить, какая из двух записей содержит более актуальные данные. Размер дополнительных данных опять-таки получается пропорциональным общему количеству данных в БД, но сравнить это с журнальной синхронизацией нельзя, так как размер дополнительных полей достаточно мал и не увеличивается при многократных изменениях данных, а записи в журнале чаще всего целиком дублируют записи таблиц и накапливаются при последовательных изменениях.
Сведем рассмотренные нами преимущества и недостатки в единый список.
Преимущества
- Хорошие возможности по исправлению коллизий
Недостатки
- Низкая скорость синхронизации - пропорциональна кол-ву всех записей
- Необходимо соединение с обоими БД
- Для всех записей вводятся дополнительные поля - сравнить с журнальной синхронизацией толком нельзя
Синхронизация независимых наборов таблиц
Итак, пусть у нас есть несколько баз данных - A, B, C,... При этом изменение данных происходит (без ограничения общности) только в БД A. Еще следует отметить, что если в базах данных имеются независимые наборы таблиц, то в одном таком наборе данные могут изменяться только в БД А, а в другом - только в базе B (например). Такая структура тоже может считаться системой с односторонней синхронизацией, просто проводимой раздельно по нескольким наборам таблиц.
Поясню примером. У фирмы есть Интернет-магазин. Одна база данных находится в офисе фирмы, вторая - на Web-сервере. Пусть есть несколько таблиц, описывающих товары Интернет-магазина и таблицы гостевой книги и форума. Эти наборы не зависят друг от друга и точки изменения данных - разные. Описания товаров заполняются в офисе и изменения должны передаваться на БД Web-сайта. А информация от клиентов - форум и гостевые сообщения создаются на сайте и идут в обратном направлении.
В такой схеме коллизии практически исключены - потоки обновлений базы не пересекаются. Реализовывать такую схему можно практически любым способом без особых проблем.
Проблемы начинаются тогда, когда в Интернет-магазин вводится функция online-покупки товара. При этом заказы покупателей являются зависимыми от таблиц товаров. И данные для этого набора могут изменяться в двух БД одновременно.
Продолжение следует...
Во второй части мы перейдем собственно к моему решению - реализации двусторонней синхронизации по текущему состоянию БД.
Каждый, кто когда-либо разрабатывал приложения, использующие базу данных, наверняка сталкивался с проблемой обновления структуры БД при разворачивании и обновлении приложения.
Чаще всего используется простой подход - создание набора SQL-скриптов для модификации структуры БД от версии к версии. Конечно, есть такой мощный инструмент, как Red gate , но он во-первых небесплатный, во-вторых не решает проблему полной автоматизации обновления.
Технология migrations, впервые появившаяся в ОРМ Hibernate и реализованная в Linq, очень хороша и удобна, но подразумевает стратегию разработки структуры БД code first, что весьма трудоемко для уже существующих проектов, а использование в БД триггеров, хранимых процедур и функций делает задачу перехода на code first практически невыполнимой.
В данной статье предлагается альтернативный подход к решению этой задачи, использующий хранение эталонной структуры БД в XML-файле и автоматическую генерацию SQL-скрипта на основе сравнения эталонной и существующей структуры. Итак, начнем...
Генерация XML-файла со структурой БД
Для экспериментов будем использовать БД DbSyncSample. Скрипт для создания БД приведен ниже.
USE GO /****** Object: Table . Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE .( IDENTITY(1,1) NOT NULL, (50) NULL, NULL, (18, 2) NOT NULL, CONSTRAINT PRIMARY KEY CLUSTERED ( ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ) ON GO CREATE NONCLUSTERED INDEX ON . ( ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON GO /****** Object: Table . Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE .( IDENTITY(1,1) NOT NULL, (150) NULL, NULL, (18, 2) NOT NULL, CONSTRAINT PRIMARY KEY CLUSTERED ( ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ) ON GO /****** Object: Trigger Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TRIGGER . ON . AFTER INSERT,UPDATE AS BEGIN UPDATE Orders SET TotalCost = s.Total FROM (SELECT i.OrderId OId, SUM(d.Cost) Total FROM Details d JOIN inserted i ON d.OrderId=i.OrderId GROUP BY i.OrderId) s WHERE Id=s.OId END GO /****** Object: Trigger Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TRIGGER . ON . AFTER DELETE AS BEGIN UPDATE Orders SET TotalCost = s.Total FROM (SELECT i.OrderId OId, SUM(d.Cost) Total FROM Details d JOIN deleted i ON d.OrderId=i.OrderId GROUP BY i.OrderId) s WHERE Id=s.OId END GO /****** Object: Default Script Date: 06/01/2017 10:37:43 ******/ ALTER TABLE . ADD CONSTRAINT DEFAULT ((0)) FOR GO /****** Object: Default Script Date: 06/01/2017 10:37:43 ******/ ALTER TABLE . ADD CONSTRAINT DEFAULT ((0)) FOR GO /****** Object: ForeignKey Script Date: 06/01/2017 10:37:43 ******/ ALTER TABLE . WITH CHECK ADD CONSTRAINT FOREIGN KEY() REFERENCES . () GO ALTER TABLE . CHECK CONSTRAINT GO
Для экспериментов создаем консольное приложение. Подключаем к нему nuget-пакет Shed.DbSync .
Структуру БД в виде XML получаем следующим образом:
class Program { private const string OrigConnString = "data source=.;initial catalog=FiocoKb;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"; static void Main(string args) { // получаем XML со структурой БД var db = new Shed.DbSync.DataBase(OrigConnString); var xml = db.GetXml(); File.WriteAllText("DbStructure.xml", xml); } }
После запуска программы в файле DbStructure.xml видим следующее:
Разворачивание/обновление структуры БД при помощи полученного XML.
Теперь научимся использовать полученный XML. Создаем еще одну пустую БД DbSyncSampleCopy, в код нашей консольной программы добавляем следующее:
class Program { private const string OrigConnString = "data source=.;initial catalog=DbSyncSample;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"; private const string TargetConnString = "data source=.;initial catalog=DbSyncSampleCopy;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"; static void Main(string args) { // получаем XML со структурой эталонной БД var dborig = new Shed.DbSync.DataBase(OrigConnString); var xml = dborig.GetXml(); File.WriteAllText("DbStructure.xml", xml); // если нужно предварительно очистить структуру целевой БД, используем // Shed.DbSync.DataBase.ClearDb(TargetConnString); // обновляем структуру целевой БД var dbcopy = Shed.DbSync.DataBase.CreateFromXml(xml); dbcopy.UpdateDb(TargetConnString); // на самом деле можно обойтись одной строкой: // dborig.UpdateDb(TargetConnString); // dbcopy создаем только для демонстрации создания объекта базы из XML } }
После запуска программы можно убедиться, что в DbSyncSampleCopy появилась структура таблиц, идентичная эталонной БД. Эксперименты с изменением эталонной структуры и обновлением целевой оставляю читателю.
В сценариях тестирования может понадобиться создание тестовой БД каждый раз с нуля. В этом случае будет полезно использовать функцию Shed.DbSync.DataBase.ClearDb(string connString)
Автоматическое слежение за структурой БД.
Слежение за структурой оформим в виде отдельной функции, которую следует вызывать при старте/рестарте приложения либо в другом месте по желанию разработчика.
static void SyncDb() { // автоматическое слежение за структурой БД Shed.DbSync.DataBase.Syncronize(OrigConnString, @"Struct\DbStructure.xml", // путь к файлу структуры @"Struct\Logs", // путь к папке логов синхронизации @"Struct\update_script.sql" // (необяз.) в случае определения этого параметра // в него будет записан скрипт, сгенерированный // для обновления БД); }
Слежение производится при помощи параметра (тега) Version в XML. Сценарий использования процедуры такой:
- Назначить версию БД. В Microsoft SqlServer Management Studio на узле нужной базы данных правой кнопкой выбрать Properties.
- Далее Extended Properties и в таблице свойств добавить свойство Version со значением 1. При каждой последующей модификации структуры это свойство следует наращивать на 1.
- При запуске приложения, если XML-файла нет или его версия меньше, чем у БД, он создается.
- Если версия XML-файла больше, чем у БД, генерируется скрипт на обновление БД и исполняется.
- Если в процессе исполнения скрипта возникли ошибки, все изменения откатываются.
- Результаты синхронизации пишутся в log-файл, создаваемый в папке, указанной параметром logDitPath.
- Если указан параметр SqlScriptPath, создается файл со скриптом из п.4.
Эксперименты оставляю читателям. Успехов вам!
Теги:
- ms sql
- синхронизация баз данных
- database
- syncronize
- dbsync
- sql
- shed
- shed.dbsync
Примерно два года назад я родил проект- небольшая программа клиент, которая ставится на любой девайс и просто синхронизирует файлы.
Например можно было задать, что документы будут синхронизироватся между домашним и рабочим компьютером. Музыку и книги между домашним компом и телефоном. Резервное копирование между домашним компом, рабочим компом и сервером. Также эта программа могла контролировать последующее распространение любого файла в системе. Т.е вы как владелец, могли всегда узнать историю файла: копирование на флешку, на другой компьютер, по «электропочте» и т.д.
Тогда я почти уже получил финансирование, но инвестиционный фонд с которым я работал в последний момент потребовал серьезную долю в бизнесе. И я решил что овчинка выделки не стоит. А потом как-то стало не до этого.
PS
Спасибо Мурину Саше за наводку)
Чтение каталога осуществляется по команде get-childitem. Чтобы учитывались вложенные папки, к ней добавляется опция -recurse, а чтобы отличать файлы от папок, используется функция PSIsContainer (). Если она возвращает значение True, то элемент - папка, в ином случае - обычный файл:
$source = ¨c:files¨
$srcfolder = get-childitem $source -recurse | where-object {$_.psiscontainer}
$srcfiles = get-childitem $source -recurse | where-object {!$_.pciscontainer}
Для решения нашей несложной задачи потребуются четыре списка: первые два содержат исходные файлы и папки, а два оставшихся - итоговые файлы и папки. Процесс синхронизации сводится к перебору этих списков и копированию файлов из одной папки в другую.
В первом цикле проверяется, существуют ли в папке для резервного хранения исходные каталоги, и если их еще нет, то они создаются посредством команды new-item.
foreach ($folder in $srcfolders)
$srcpath = $source -replace ¨\¨,¨\¨ -replace ¨:¨,¨:¨
$dstpath = $folder.fullname -replace $srcpath,$destination
if ($dstpath -ne ¨¨) {
if (! (test-path $dstpath))
¨Создание папки ‘$dstpath’.¨
new-item $dstpath -type directory | out-null
Очень похожий цикл выполняется и при сравнении результирующего и исходного списка папок, тем самым создается точная структура вложенных папок. Два других цикла обрабатывают файлы: первый копирует обновленные объекты из исходной в результирующую папку, второй - отсутствующие в исходном каталоге - из итогового. Узнать, обновился ли файл, можно по его хэш-коду. Заметим, что, поскольку файлы открываются в режиме «только чтение», они не блокируются от использования другими программами. Впрочем, по правилам хорошего тона файл по окончании вычисления хэш-кода необходимо закрывать функцией Close ():
$md5 = new-object system.security.cryptography.md5cryptoserviceprovider
$fs = new-object system.io.filestream ($file,$mode,$access)
$hash = $md5.computehash ($fs) # хэш-код файла
$fs.close ()
Рис. 1. Результат анализа отслеживаемых папок в GoodSync
После этого можно вручную запустить синхронизацию данных (кнопка Синхронизация ), однако удобнее настроить программу на автоматическое выполнение операции. С этой целью открывают встроенный в утилиту планировщик и определяют время синхронизации либо событие, при наступлении которого программа должна запускать анализ и синхронизацию файлов (рис. 2).
Рис. 2. Настройка автоматической синхронизации в GoodSync
Стоит обратить внимание на один нюанс. При автоматической синхронизации файлов на портативный накопитель (например, флэшку) может возникнуть проблема распознавания диска. Удобнее, если запуск обработки файлов начинается автоматически при подключении уникального устройства, однако любой USB-диск при подключении будет фигурировать под одной и той же буквой, что в случае вставки другой флэшки приведет к ошибкам синхронизации. Для того чтобы программа могла правильно распознать нужный диск , требуется вручную изменить путь до устройства, заменив в нем букву диска на метку тома (=VolumeName:\folder1\folder2 - рис. 3). Соответствующую метку тома для конкретного диска несложно установить в свойствах, воспользовавшись проводником Windows . Применение указанных настроек гарантирует обнаружение нужного портативного накопителя независимо от присвоенной ему буквы диска.
Рис. 3. Замена буквы диска меткой тома
в GoodSync
ViceVersa
Разработчик: TGRMN Software
Размер дистрибутива: Pro - 3,4 Мбайт; Plus - 1,1 Мбайт; Free - 708 Кбайт
Работа под управлением: ViceVersa Pro 2.5 и ViceVersa Plus 2.4.2 - Windows (все версии); ViceVersa Free 1.0.5 - Windows XP/Vista/7
Цена: Pro - 59,95 долл.; Plus - 34,95 долл.; Free - бесплатно
ViceVersa Pro - известное решение для синхронизации, резервного копирования и репликации файлов и папок (рис. 4). С его помощью можно синхронизировать данные между стационарными компьютерами, ноутбуками, файловыми серверами, внешними носителями (жесткими дисками, USB-устройствами, ZIP-дисками и пр.), NAS и т.д. Реализуется это по локальной сети , через Интернет и с применением любых внешних накопителей .
При синхронизации анализируются такие параметры, как размер файла и дата/время создания файлов, контрольные суммы либо совокупность перечисленных параметров. Предусмотрена возможность включения/исключения при анализе подкаталогов, а также отдельных файлов с учетом их атрибутов (скрытые/системные/только для чтения) и маски. Допускается синхронизация и резервное копирование открытых и заблокированных приложениями файлов, включая почтовые базы Outlook и Outlook Express, документы Word и Excel и базы данных SQL. Синхронизация данных производится вручную по требованию или в автоматическом режиме - по расписанию (например, ежедневно в строго определенное время). В целях экономии дискового пространства и обеспечения безопасности данных на любом носителе в программе предусмотрен инструментарий для сжатия и шифрования файлов.
Утилита выпускается в трех редакциях: бесплатной Free (http://www.tgrmn.com/free/) и двух коммерческих - базовой Plus и расширенной Pro. Возможности бесплатной редакции ограничены сравнением и синхронизацией файлов в папках (включая подпапки) между накопителями на гибких дисках, жесткими и сетевыми дисками, а также ZIP- и компактдисками; синхронизация производится вручную. Редакция Plus позволяет работать с USB-накопителями, жесткими и сетевыми дисками, а также DVD/CD, обеспечивает возможность синхронизации/резервирования открытых/заблокированных файлов и может быть настроена на работу по расписанию. В редакции Pro поддерживается весь заявленный разработчиками функционал.
GoodSync 8.8.6
Разработчик: Siber Systems, Inc.
Размер дистрибутива: 7,15 Мбайт
Работа под управлением: Windows 2000/XP/Vista/7
Цена: 29,95 долл.
GoodSync - удобный и простой инструмент для синхронизации и резервного копирования файлов (рис. 5). Программа позволяет синхронизировать файлы между настольными и переносными компьютерами, съемными дисками и серверами, а также проводить резервное копирование важных данных на различные носители (включая FTP- и WebDAV-серверы). Кроме того, предусмотрена возможность синхронизации файлов между устройствами Windows Mobile Phone или Pocket PC (Windows CE) и настольным компьютером. Синхронизация может проводиться напрямую между компьютерами (в локальной сети или через Интернет с FTP-, WebDAV- и Secure FTP-серверов) либо с подключением любых внешних накопителей (USB-диска, внешнего HDD).
Анализ данных проводится с учетом даты/времени модификации файлов или их размера. В ходе анализа автоматически игнорируются скрытые и системные файлы , можно настроить включение/исключение файлов с именами, соответствующими определенной маске, а также файлов определенного размера или с определенным временем изменения. Возможна синхронизация заблокированных файлов с применением службы Volume Shadow Copy. Для автоматизации процесса синхронизации включен инструментарий для запуска синхронизации по расписанию, а также при наступлении определенных событий (например, при подключении компьютера к локальной сети, при подключении съемного диска к компьютеру или при запуске системы) допускается применение планировщика Windows. В целях повышения безопасности при удаленной синхронизации данных реализована передача файлов по шифрованному каналу (FTP через SSH и WebDAV через SSL), а при резервном копировании возможно использование шифрованной файловой системы EFS (Encrypting File System).
Программа имеет демо-версию, которая полностью функциональна в течение 30 дней. В дальнейшем она может применяться домашними пользователями и некоммерческими структурами совершенно бесплатно, но с ограничениями - разрешается создавать до трех заданий синхронизации, включающих не более ста файлов. Имеется специальная портативная редакция утилиты - она фигурирует под названием GoodSync2Go и предназначена для установки на USB-диски.
Allway Sync 11.6.1
Разработчик : Botkind, Inc.
Размер дистрибутива: 6,9 Мбайт
Работа под управлением: Windows 2000/XP/2003/Vista/2008/7
Цена: зависит от лицензии: Pro - 29,99 долл.; Free - бесплатно (только для некоммерческого использования)
Allway Sync - простая в применении утилита, предназначенная для синхронизации и резервирования файлов в папках (рис. 6). Программа обеспечивает синхронизацию данных между настольными ПК, ноутбуками, внешними жесткими дисками, USB-дисками, FTP/SFTP-серверами и различными онлайновыми хранилищами данных. Анализ информации и ее обновление производятся по локальной сети, через Интернет и посредством внешних накопителей (флэшек, внешних жестких дисков и т.д.).
Последние версии файлов выявляются на основе комбинации атрибутов файла, его размера и времени создания. В целях сужения перечня анализируемых файлов допускается включение/исключение объектов синхронизации с учетом места нахождения файла, имени и атрибутов (только включение/исключение скрытых/системных файлов). Синхронизация может проводиться по требованию и автоматически - через определенный промежуток времени, при подключении съемного устройства, при простое компьютера и др.; возможно использование планировщика задач Windows.
Программа предлагается в двух редакциях: бесплатной Free и коммерческой Pro. Бесплатная редакция позволяет синхронизировать не более 40 тыс. файлов в 30-дневный срок. Имеется специальная портативная редакция утилиты, предназначенная для установки на флэшку или внешний HDD.
FreeFileSync 4.2
Разработчик: ZenJu
Размер дистрибутива: 9,27 Мбайт
Работа под управлением: Windows 2000/XP/Vista/7
Цена: бесплатно
Не стоит забывать и про актуальность копий, для чего следует проводить периодическую синхронизацию. Можно, конечно, каждый раз копировать весь объем данных заново, но это подойдет только в случае, если таковых немного. Для больших объемов это приведет к лишнему износу жесткого диска и, в общем то, пустой трате времени. Синхронизация производится гораздо быстрее, чем полное копирование, но очень важно ее правильно настроить. Иначе можно потерять и копию, и оригинальные данные! Перед использованием синхронизации обязательно протестируйте её на ненужных файлах и папках!
Настройка синхронизации в FreeFileSync
После установки запускаем программу и выбираем папки для синхронизации. Слева будет оригинальная папка, а справа - резервная копия на внешнем жестком диске.
Затем, заходим в настройки сравнения файлов и выбираем параметры. По умолчанию файлы сравниваются по дате и размеру. На вкладке «Фильтр» можно настроить папки и файлы, которые необходимо исключить из синхронизации.
На вкладке «Синхронизация» настраиваем режим синхронизации. Всего предусмотрено 4 режима:
- В обе стороны - отслеживаются изменения с обоих сторон синхронизации.
- Зеркало - учитываются только изменения с левой стороны, то есть файлы и папки, несуществующие слева, будут удалены при синхронизации.
- Обновить - файлы копируются слева на право, при этом в случае, если справа встречаются новые файлы, требуется вмешательство пользователя.
- Выборочно - можно настроить свои правила обработки файлов.
Настройка синхронизации по расписанию
FreeFileSync имеет полезную функцию - это сохранение параметров синхронизации в виде пакетного файла. Для создания этого файла нажимаем кнопку «сохранить как пакетное задание». Если необходимо, то можно включить запись логов синхронизации.
При запуске этого файла синхронизация выполняется в скрытом режиме, без запуска графического интерфейса . Следовательно, в Windows можно настроить выполнение этого файла по расписанию. Для этого открываем панель управления Windows и находим там пункт «Расписание выполнения задач». В качестве примера, настроим запуск синхронизации при включении компьютера. Создаем задачу для всех пользователей. При этом на компьютере обязательно должен быть задан пароль.
В качестве триггера указываем «При запуске». Стоит также задать отсрочку выполнения, чтобы все сработало корректно.
Небольшой бесплатный синхронизатор папок и файлов для бытовых нужд.
Наличие двух (а иногда и более) компьютеров в домашнем использовании уже давно перестало восприниматься как нечто из ряда вон выходящее. Сегодня в домашней локальной сети можно обнаружить до десятка различных устройств, как самих ПК, так и всевозможных сетевых накопителей, DVD и Blue-Ray-проигрывателей, телевизоров с доступом к сети и т.п. Даже, если у Вас нет всего вышеперечисленного, то все равно, наверняка Вы пользуетесь хотя бы одной флэшкой для переноса нужных данных. В любом случае возникают ситуации, когда нужный файл изменяется на локальном компьютере и приходится вручную переносить его на ту же флешку. А если таких файлов несколько, как не забыть вовремя «скинуть» актуальные копии? Для всего этого существуют специальные программы - синхронизаторы.
Хороший синхронизатор должен уметь работать одинаково как с локальными папками, так и со съемными и удаленными носителями информации, отслеживать изменившиеся файлы в указанной директории и вовремя обновлять их в конечной папке, работать по заданному расписанию в автоматическом и/или скрытом режиме… Всеми этими (и некоторыми другим) возможностями обладает очень небольшая утилитка DSynchronize . Несмотря на бесплатный статус и маленький размер она может смело потягаться на равных с коммерческими программами, например такими, как популярная за рубежом Synchromagic Pro .
Сравнение программы DSynchronize с платным аналогом Synchromagic Pro
DSynchronize имеет достаточно простой интерфейс и довольно неплохую функциональность, поэтому ее можно смело предлагать как для домашнего, так и для корпоративного использования. Большим плюсом является еще и то, что программа может работать в режиме службы, что позволяет простому пользователю даже не задумываться о синхронизации файлов вручную и иметь под рукой только самые актуальные их версии, единожды настроив расписание работы DSynchronize .
К минусам программы (хотя кому как:)) можно отнести неспособность DSynchronize архивировать копируемые файлы для возможного их последующего восстановления. Функция бэкапа вроде бы присутствует в виде окошка «Резервная копия » , но на деле обнаружить какие-нибудь копии не удалось ни в папке с программой, ни в синхронизируемых директориях:(. Все же я не склонен относить сей недостаток к минусам, поскольку старыми версиями файлов мы вряд ли будем пользоваться, а если даже и пользуемся, то наверняка создаем копии сами.
Итак, теперь о работе с программой. DSynchronize не требует установки, однако для сохранения настроек следует все же разархивировать ее в любую папку на жестком диске. Все, можем приступать к работе.
Интерфейс DSynchronize
Изначально интерфейс программы английский, хотя и интуитивно понятен. На официальном сайте русская локализация отсутствует, однако мною была сделана попытка «одомашнить» DSynchronize .. Чтобы русифицировать программу достаточно в папку, в которую Вы ее распаковали, добавить файл DSynchronize.lng из скачанного архива (ах, да… разрешается любая модификация и оптимизация вышеупомянутого файла под свои нужды:))). Теперь запустим уже русский вариант DSynchronize .
Условно интерфейс окна DSynchronize можно разделить на три части. Вверху расположены списки пар директорий для синхронизации, ниже - панель настроек всех процессов, а еще ниже три окошка, которые отражают работу с файлами. В самом начале в списке заданий мы увидим два примера. Их следует удалить при помощи соответствующей команды в контекстном меню (правая кнопка мыши). Когда список стандартных задач будет очищен, добавим собственные. Снова вызываем контекстное меню и выбираем пункт «Добавить» . Появится пара пустых строк. В эти строки мы и впишем полные адреса папок, файлы в которых подлежат синхронизации.
Теперь есть несколько нюансов. Если Вы планируете синхронизировать две локальные папки , то достаточно будет дважды кликнуть на строке и, нажав кнопку «Обзор» , выбрать из вписка вначале исходную папку (из которой будут копироваться файлы), а затем конечную. То же самое следует сделать, если Вы хотите синхронизировать папку со съемным носителем информации (например, с флэшкой), предварительно подключив устройство к ПК.
Синхронизация по FTP
А вот чтобы подключиться к удаленному компьютеру по локальной сети или по FTP, придется вводить путь вручную . Чтобы получить доступ к папке на удаленном ПК по локальной сети потребуется ввести следующее: \\Имя компьютера (или его IP)\Имя папки (например, \\192.168.1.4\Общие Документы). Единственный нюанс, папка, к которой мы подключаемся должна быть открыта для общего доступа. Вызовите контекстное меню папки и выберите пункт «Свойства» . В открывшемся окошке перейдите на вкладку «Доступ» и отметьте галочкой пункт «Открыть общий доступ к этой папке» .
Чтобы воспользоваться возможностью синхронизации по FTP укажите полный адрес сервера (например, ftp://Адрес сервера/Имя папки). Если в ответ Вы получите окошко с сообщением об ошибке, значит, для доступа к серверу требуется указать данные для авторизации. Сделать это можно, дописав перед адресом сервера вначале логин, затем после двоеточия пароль, и только потом после значка «@» непосредственный адрес сервера (см. скриншот выше).
Когда синхронизируемая пара папок готова, можно настроить некоторые параметры обмена файлами. Для этого кликните на кнопку «Фильтр» рядом с адресом папки, либо вызовите соответствующую команду из контекстного меню.
Здесь мы можем задать копирование либо строго определенных файлов или их типов по маске, указав пункт «Включения фильтра» , либо указать, какие файлы (или типы файлов) не следует синхронизировать, выбрав пункт «Исключения из фильтра» . Маска задается стандартным образом: мы вводим часть имени файла, а все, что не нужно помечаем как «*» . Разделять маски можно обычной точкой с запятой. Далее есть пара опций, которые определяют параметры работы с подпапками, а еще ниже находится раздел «Расширенные фильтры» . Здесь можно исключить из копирования файлы, измененные в определенный день.
Настройки DSynchronize
Рассмотрим теперь панель опций , которая расположена под списком папок.
Все возможности разделены на четыре группы. Первая - «Главные опции» - включает в себя практически все необходимые настройки синхронизации. Стоит обратить внимание на первые две возможности. Пункт «Только новейшие» позволяет не переписывать все существующие файлы, а копировать только самые актуальные версии. Таким образом, значительно экономится время, затрачиваемое на синхронизацию. Другая возможность - «Двойная синхронизация» . Если она активирована, то на наличие новых версий файлов проверяются обе папки и в итоге в каждой из них остаются только самые актуальные копии.
Вторая группа настроек - «Специальные опции» . Здесь можно включить антифрагментацию добавленных файлов, пропуск ошибок, а также резервное копирование (которое на деле не работает:(). Из всех доступных здесь опций полезна по сути лишь «Антифрагментация» . Если она активирована, то при нахождении новой версии файла, старая удаляется, а новая версия добавляется, как новый файл. Это позволяет добиться меньшей фрагментации, чем, если бы старый файл просто заменялся новым.
Четвертая группа - «Команды» - содержит только кнопки управления процессом синхронизации, поэтому подробнее остановимся на третьей группе - «Планирование» . Это один из самых основных разделов, который отвечает за автоматизацию всех процессов в работе DSynchronize . Кликнув по первой же опции - «Таймер» , мы перейдем в окно настройки синхронизации по времени:
Здесь есть возможность задать синхронизацию через определенный промежуток времени или в конкретный момент (в час дня, например). Кроме того, мы можем настроить процесс сличения файлов не только каждый день, но и в строго определенные дни месяца или недели!
Есть возможность в DSynchronize задать постоянную синхронизацию в режиме реального времени при помощи пункта «Real-time» . Правда эта возможность пока экспериментальная, о чем нас и предупредят при попытке включения, поэтому перед ее активацией следует убедиться, что программа корректно работает с выбранными папками в обычном режиме.
Далее здесь следует два пункта, которые отвечают за автозапуск DSynchronize . Первый - «Автостарт» , позволяет загружать программу вместе с системой. В этом случае программу будет видно в трее, из которого ее всегда можно вызвать. Если же Вы уверены, что все настроили правильно и постоянный доступ к DSynchronize Вам не нужен, то Вы можете установить работу программы в режиме службы. Для этого отметим пункт «Запуск службы…» .
В открывшемся окне сначала потребуется нажать кнопку «Install Service» для установки новой службы, а затем запустить ее, после чего останется нажать только кнопку «Готово» .
Пример работы с программой
Теперь все действительно готово для того, чтобы начинать работу, поэтому жмем кнопку «Синхронизация» в разделе «Команды».
Сам процесс синхронизации происходит в два этапа, что можно видеть в статусной строке. Первый этап - сличение и формирование списка копируемых файлов, второй - непосредственное копирование. В трех окошках под основным меню мы можем видеть списки всех скопированных, удаленных или замененных файлов. Здесь же мы можем установить и определенные запреты или разрешения на соответствующие действия. Если Вы хотите держать под контролем весь процесс синхронизации, советую включить запрос перед любым действием DSynchronize (кроме, пожалуй, добавления файлов). Такие запросы выглядят следующим образом:
В данном случае перед нами окно подтверждения замены файлов (Confirm Add - подтверждение на добавление, Confirm Remove/Delete - удаление).
О завершении процесса синхронизации мы узнаем опять же из надписи в статусной строке:
Поздравляю Вас! Теперь Вы наконец-то можете забыть о ручном копировании нужных файлов, так как сможете переложить все заботы связанные с синхронизацией файлов на DSynchronize .
P.S. Данная статья предназначена для свободного распространения. Приветствуется её копирование с сохранением авторства Руслана Тертышного и всех P.S. и P.P.S.
P.P.S. Если Вы любите решения типа «все в одном», то советую присмотреться к следующему файловому менеджеру, который в числе прочих имеет возможность синхронизировать указанные каталоги.
Примерно два года назад я родил проект- небольшая программа клиент, которая ставится на любой девайс и просто синхронизирует файлы. Например можно было задать, что документы будут синхронизироватся...
Примерно два года назад я родил проект- небольшая программа клиент, которая ставится на любой девайс и просто синхронизирует файлы. Например можно было задать, что документы будут синхронизироватся...
Синхронизация баз данных MySQL позволяет создать и автоматически поддерживать две или более базы данных с идентичным содержимым. Синхронизациия нужна для создания зеркал, кластеров и т.д. Программа Handy Backup позволяет полностью автоматизировать процесс синхронизации БД MySQL.
Методы синхронизации MySQL баз
В MySQL синхронизация двух баз может быть односторонней или двусторонней.
Односторонняя синхронизация
Содержимое одной базы (master) копируется в другую (slave). В MySQL синхронизация БД на разных серверах используется для репликации таблиц, создания тестовых и резервных баз, бэкапа MySQL и т.д.
Двусторонняя синхронизация
Двусторонняя синхронизация MySQL обеспечивает копирование актуальных изменений из каждой базы данных в другую. Эта техника применяется прежде всего для распределения вычислительных задач, связанных с базами данных – создания кластеров и зеркал БД.
Преимущества Handy Backup для синхронизации БД MySQL
Handy Backup содержит встроенный плагин MySQL, позволяющий копировать состояние баз данных и таблиц MySQL в "горячем" режиме (без остановки сервера), а также в "холодном" (с остановкой). При этом обеспечиваются следующие преимущества:
- Синхронизация данных MySQL (копирование и восстановление) по расписанию;
- Хранение таблиц MySQL в удобочитаемом текстовом формате из списка SQL команд;
- Автоматический останов сервера-приёмника MySQL при восстановлении данных;
- Версионное копирование и создание временных меток на копиях по необходимости;
- Получение доступа к внешним MySQL серверам.
Как выполнить синхронизацию MySQL с помощью Handy Backup?
Синхронизация баз данных MySQL состоит из создания резервной копии базы и последующего восстановления таблиц этой базы на другом сервере с помощью плагина "MySQL". Этот процесс включает в себя 2 последовательных задачи:
Резервное копирование данных исходной таблицы (в случае односторонней синхронизации) или обеих таблиц (при симметричной синхронизации).
Восстановление данных в синхронизируемую таблицу MySQL, полное или дифференциальное, в зависимости от типа синхронизации.
Детальное описание задач копирования и восстановления MySQL имеется в Руководстве Пользователя.
Автоматизация задач синхронизации таблиц MySQL
Чтобы сделать процесс синхронизации баз данных MySQL полностью автоматическим, обратите, пожалуйста, внимание на следующие пункты:
- Разделите время запуска задач резервного копирования MySQL и их восстановления на достаточно большой промежуток, чтобы запущенная задача резервного копирования базы данных успела завершиться перед началом восстановления.
- Выбирайте для промежуточных копий MySQL достаточно быстрые по скорости доступа носители: локальные и внешние диски, устройства NAS/SAN и серверы FTP/SFTP/FTPS с широкой пропускной способностью сетевого интерфейса.
- Пользуйтесь возможностями Шага 7 (установка запуска программ до и/или после выполнения задачи) для автоматического останова и перезапуска сервера MySQL на стороне восстановления, а также на стороне записи – для "холодной" загрузки данных.
- Поскольку резервные копии хранятся в доступном для чтения текстовом формате, пользуйтесь при необходимости инструментами для внесения исправлений в восстанавливаемые файлы – скажем, для смены механизма хранения данных.
Приобретение лицензии
Как было сказано выше, синхронизация баз данных (БД) MySQL не заменяет регулярного резервного копирования. Мы рекомендуем обеспечивать задачи резервного копирования БД MySQL с помощью одного из бизнес-ориентированных решений нашего программного обеспечения (ПО).
- Если вам нужно работать только с одним сервером СУБД MySQL, Handy Backup Office Expert обеспечит вас всеми необходимыми возможностями для этого и многими дополнительными функциями.
- Если вам необходимо обслуживать несколько серверов и рабочих станций, организуя процессы резервного копирования БД MySQL и любых других данных с общего рабочего места, используйте наше флагманское решение Handy Backup Server Network .
Чтобы сравнить цены на эти и другие продукты, пожалуйста, обратитесь к странице Купить .
Видеоурок
В следующем видеоуроке показано, как осуществлять резервное копирование и восстановление БД MySQL с помощью Windows-версии Handy Backup. В настоящий момент видео доступно только на английском языке.
Скачайте и установите наше программное обеспечение прямо сейчас – первая резервная копия ваших данных будет готова уже через пару минут!
Handy Backup предоставляет надёжный, быстрый и гибко настраиваемый инструмент для синхронизации MySQL на уровне таблиц и баз данных. Попробуйте прямо сейчас, скачав бесплатно полную версию программы на 30 дней!
Загрузка...
