CC BY
127
Communication-Based Systems, 2003. P. 109-123.
4. Питерсон Дж. Теория сетей Петри и моделирование систем: пер. с англ. М.: Мир, 1984. 264 с.
5. Троелсен Э. Язык программирования С# 2010 и платформа .NET 4.0. М.: ООО «И. Д. Вильямс», 2011. 1392 с.
Ивутин Алексей Николаевич, канд. техн. наук, доц., alexey.ivutin@,gmail.com, Россия, Тула, Тульский государственный университет,
Страхов Илья Андреевич, магистрант, [email protected], Россия, Тула, Тульский государственный университет
PETRI NETS AND EXTENSIONS FRAMEWORK
A.N. Ivutin, I.A. Strahov
Developed a framework, which is a standard feature of Petri nets. This framework is used in the development of tools for the modeling of Petri-Markov nets. A version of the software interface of the simulation of Petri-Markov nets are proposed.
Key words: Petri-Markov net, simulating, software, framework, tools
Ivutin Alexey Nicolaevich, candidate of technical science, docent, [email protected], Russia, Tula, Tula State University,
Strahov Ilia Andreevich, undergraduate, iastrahov@,gmail. com, Russia, Tula, Tula State University
УДК 004.658.6
ПОВЫШЕНИЕ НАДЕЖНОСТИ И ПРОИЗВОДИТЕЛЬНОСТИ БАЗ ДАННЫХ ПРИ ПОМОЩИ РЕПЛИКАЦИЙ
А.Н. Ивутин, И.С. Терехин
Описаны типы репликации (Синхронная репликация, Асинхронная репликация). Рассмотрены задачи, которые может решить метод репликации базы данных, а также недостатки использования метода. Обозначены проблемы, когда такой подход необходим.
Ключевые слова: репликация, база данных, производительность.
Ежегодно все больше сфер человеческой деятельности переходят на электронный вариант хранения данных. Для этого используются разнообразные системы управления баз данными (СУБД), такие как MSSQL, Oracle, MySQL и другие. Скорость работы современных реляционных
140
СУБД позволяет изменять и считывать тысячи строк информации в секунду. Базы данных намного упростили процесс ведения учета бухгалтерии, поиск информации, предоставление услуг посредством сети интернет и т.д.
Возможно зайти на портал государственных услуг и заказать справку, записаться на прием к врачу или узнать количество набранных баллов после сдачи единого государственного экзамена. В современном мире для всего этого не требуется выходить из дома, стоять в очередях, пропуская обеденный перерыв.
Такие возможности доступны благодаря беспрерывно работающим удаленным системам. И в данных ситуациях совершенно неприемлемо, если по техническим причинам нельзя получить необходимую информацию. Чаще всего в таких случаях дают сбой именно базы данных. Для этого следует сделать систему отказоустойчивой.
Один из способов разработки отказоустойчивых баз данных - создание их реплик.
Репликация (от лат. герНсо - повторяю) - это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других), и наоборот. При репликации изменения, сделанные в одной копии объекта, могут быть распространены в другие копии.
Репликация в базах данных — это тиражирование изменений данных с главного сервера баз данных на одном или нескольких зависимых серверах. Главный сервер при этом будет называться мастером, а зависимые сервера - репликами.
Репликация может быть синхронной и асинхронной:
- Синхронной репликация называется, при обновлении данных сервера и всех других реплик того же фрагмента в одной и той же транзакции. Логически это означает, что существует лишь одна версия данных. В большинстве продуктов синхронная репликация реализуется с помощью триггерных процедур. Но синхронная репликация имеет тот недостаток, что она создаёт дополнительную нагрузку при выполнении всех транзакций, в которых обновляются какие-либо реплики (кроме того, могут возникать проблемы, связанные с доступностью данных).
- Асинхронной репликация называется, в случае обновления данных одной реплики, которые распространяется на другие спустя некоторое время, а не в той же транзакции. Таким образом, при асинхронной репликации вводится задержка, или время ожидания, в течение которого отдельные реплики могут быть фактически неидентичными. В большинстве продуктов асинхронная репликация реализуется посредством чтения журнала транзакций или постоянной очереди тех обновлений, которые подлежат распространению. Преимущество асинхронной репликации состоит в том, что дополнительные издержки репликации не связаны с транзакциями обновлений, которое имеет важное значение для функционирования, и предъявлять высокие требования к производительности. К недостаткам
этой схемы относится то, что данные на репликах не всегда идентичны.
Изменения данных, происходящие на мастере, повторяются на репликах (но не наоборот). Поэтому запросы на изменение данных (добавление, изменение, удаление и т. д.) выполняются только на мастере, а запросы на чтение данных, могут выполняться как на репликах, так и на мастере. Процесс зеркалирования на одной из реплик не влияет на работу других баз данных, и практически не влияет на работу мастера.
Репликация происходит при изменении журнала, который создается или изменяется при изменении данных на основном сервере базы данных. В журнал сохраняются все запросы к базе данных, приводящие к изменениям данных в ней. При этом запросы сохраняются не в явном виде, поэтому разобрать их вручную достаточно сложно и, как правило, задача решается при помощи специальных программных утилит. Важной особенностью является то, что при репликации передаются не сами измененные данные, а только кодированные запросы, вызывающие изменения.
После изменения, журнал, передается базам данных реплик, начиная с позиции п+1, где п - последняя выполненная позиция из бинарного лога. После этого журнал декодируется, и выполняются описанные в нем действия.
Таким образом, при репликации содержимое базы данных дублируется на одном или нескольких серверах как показано на рисунке.
Создание реплик решает сразу несколько задач по повышению надежности и производительности системы.
- Производительность и масштабируемость. Если один сервер не справляется с нагрузкой, создаваемой одновременными операциями чтения и записи в базу данных. Запросы на чтение данных можно перенаправить на реплики, при этом выгода такой системы будет весомей, если на одну операцию записи происходит несколько операций чтения.
- Отказоустойчивость. При отказе одной из реплик, запросы чтения можно распределить по другим репликам или перевести все запросы на мастер, если была лишь одна реплика. В случае отказа мастера, запросы на запись можно перевести на одну из реплик, а после того как мастер будет восстановлен, его можно сделать репликой.
- Резервирование данных. При использовании реплики мы всегда уверены что есть, «страховочная» база данных, практически идентично повторяющая основную.
- Сложные вычисления. Сложные и медленные запросы к базе данных можно выполнять на отдельной реплике, не замедляя работу всей системы.
- Модернизация оборудования. При необходимости «остановить» один из серверов, для установки, например дополнительной оперативной памяти, не нарушится работа системы в целом.
База данных ' Реплика № 1
Репликация базы данных
- Возможность использования различных структур таблиц на разных серверах. К примеру, на реплике базы данных, для сложных вычислений, можно выставить альтернативный набор индексов или изменить тип таблицы.
У рассматриваемого процесса репликации есть также ряд недостатков.
- Не точная копия в единицу времени. При асинхронной репликации существует расхождение данных мастера от реплик. Так как при добавлении записи в БД мастера производится обновление журнала, который впоследствии передается репликам, декодируется и выполняется. На практике расхождение в базах данных может доходить до двух секунд.
- Проблемы с random значением. Если в запросе использовалась функция random с неопределенным значением, то на реплике это значение может быть отличным от базы данных на мастере.
При создании инфраструктуры базы данных на основе метода репликации, не критичен отказ главного сервера, работоспособность системы можно восстановить за несколько минут в ручную, или создать контроллер, который будет выполнять эти действия автоматически, сделав одну из реплик главным сервером и заменив настройки остальных реплик таким образом, чтобы они забирали журнал с нового, главного сервера, баз данных.
Метод можно улучшить при помощи создания отдельного контролера, через который будут проходить все запросы к базам данных. И именно он будет следить за распределением нагрузки по доступности реплик. В итоге, не будет главного сервера базы данных (мастер), а запросы на выборку данных будут распределяться только по тем репликам, у которых данные для запроса актуальны.
Список литературы
1. Каратыгин, С., Тихонов, А.; Долголаптев, В. Базы данных. М.: ABF, 1995. 352 с.
2. Дюбуа, П. MySQL. М.: Вильямс, 2001. 236 с.
3. Энсор, Д., Стивенсон, Й. Oracle. Проектирования баз данных. Киев: BHV, 2000. 560 с.
Ивутин Алексей Николаевич, канд. техн. наук, доц., alexey.ivutin@,gmail.com, Россия, Тула, Тульский государственный университет,
Терехин Илья Сергеевич, аспирант, terehinisagmail. com, Россия, Тула, Тульский государственный университет
IMPROVING THE RELIABILITY AND PERFORMANCE OF DATABASES VIA
REPLICATION
A.N. Ivutin, I.S. Terehin
Describes the types of replication (synchronic replication, asynchrony replication). Consider problems that can be solved by replicating the database as well as disadvantages of the method. Identified problems, when such an approach is needed
Key words: replication, the database performance.
Ivutin Alexey Nicolaevich, candidate of technical science, docent, [email protected], Russia, Tula, Tula State University,
Terehin Ilia Sergeevich, postgraduate, terehinis@gmail. com, Russia, Tula, Tula State University
УДК 004.413.5; 004.942
ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ОПТИМАЛЬНОЙ УНИФИКАЦИИ СИСТЕМНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНОЙ СЕТИ ПРЕДПРИЯТИЯ
В.Н. Изотов, Е.А. Дьяченко
Рассмотрена методика решения задачи унификации системного программного обеспечения компьютерной сети по экономическому критерию с применением метода имитационного моделирования. В основу методики положен оригинальный способ применения имитационной модели для оценки эффекта от унификации и измерения показателей качества функционирования компьютерной сети.
Ключевые слова: компьютерная сеть, программное обеспечение, унификация, имитационная модель, показатели качества, оптимизация.
Одно из перспективных направлений унификации системного программного обеспечения (ПО) корпоративной компьютерной сети (КС) предприятия с большим количеством объектов, территориально удалённых
144
