После решения вопроса , который я недавно задавал о фрагментации мнезии , у меня все еще есть ряд проблем.Рассмотрим следующий сценарий (вопрос, который я задаю, основан на нижеследующем):
У вас есть корпоративное приложение, управляемое данными, которое должно иметь высокую доступность
внутри предприятия.Если по какой-либо причине внутренний источник информации не работает,
приложения предприятия должны переключиться на выборку данных из центра восстановления
, который находится за пределами (удаленно).
Вы решаетереплицировать базу данных на два узла в пределах предприятия
(именуемые сторона БД A и сторона БД B ).Эти два устройства работают на отдельном
оборудовании, но связаны, скажем, с Fast Ethernet или оптоволоконным каналом .
Логически вы создаете некий туннель или защищенную связь между этими
двумя базами данных Mnesia.Два (A и B) должны иметь одну и ту же копию данных и все время синхронизироваться
.
Теперь центр восстановления также должен иметь одну и ту же копию данных и в
синхронизировать все время на случай, если локальный доступ к данным будет отключен из-за атаки
или аппаратного сбоя.Таким образом, одна и та же схема базы данных должна быть реплицирована на 3
сайтах ( Сторона A , Сторона B и центр восстановления ).
Теперь на предприятии промежуточное программное обеспечение приложений может переключать запросы данных между сайтами базы данных.Если A не работает, то без приложения, реализующего его, запрос перенаправляется в базу данных B и так далее.Уровень промежуточного программного обеспечения можно настроить для балансировки нагрузки (мультиплексирование запросов) или для обеспечения гибкости при отказоустойчивости.
Дальнейший анализ :
At Database/Schema creation time, all involved Nodes must be up and running <br>Mnesia. To achieve this, you create say: <b>'db_side_A@domain.com'</b>, <br><b>'db_side_B@domain.com'</b> and finally, <b>'db_recovery_center@domain.com'</b>
Сейчас, при создании таблицы вы бы хотели, чтобы ваши таблицы mnesia были фрагментированы.Таким образом, вы выбираете следующие параметры:
<b><i>n_disc_only_copies</i> =:= number of nodes involved in the pool =:= 3 </b>
<b>Reason:</b> You are following the documentation that this parameter regulates how <br>many disc_only_copies replicas that each fragment should have.<br>So you want each table to have each of its fragments on each mnesia Node.<br>
<b><i>node_pool =:= all nodes involved =:= ['db_side_A@domain.com',<br> 'db_side_B@domain.com',<br> 'db_recovery_center@domain.com'] </i></b>
Все ваши таблицы затем создаются на основе следующей схемы
Nodes = [
'db_side_A@domain.com',
'db_side_B@domain.com',
'db_recovery_center@domain.com'
],
No_of_fragments = 16,
{atomic,ok} = mnesia:create_table(<b>TABLE_NAME</b>,[
{frag_properties,[
{node_pool,Nodes},
{n_fragments,No_of_fragments},
{n_disc_only_copies,length(Nodes)}]
},
{index,[]},
{attributes,record_info(fields,<b>RECORD_NAME_HERE</b>)}]
),
ПРИМЕЧАНИЕ: В приведенном выше синтаксисе
RECORD_NAME_HERE не может быть переменной в реальности, поскольку записи должны быть известны вВремя компиляции с Erlang.Из установки вы видите, что для каждой таблицы каждый фрагмент, скажем,
table_name_frag2, появляется в файловой системе каждого узла.
Проблемы и возникающие вопросы :
После того, как чтоуказан ниже, ваш первый запуск базы данных в порядке, так как mnesia работает на всех узлах.По мере запуска приложения начинают появляться некоторые проблемы, и я перечисляю следующее:
Предположим, вы решили, что все записи сначала пробуются на DB Side A, и если сторона A в этот момент недоступнавызов повторяется на DB Side B и т. д. до recovery center, и если вызов не может вернуться на все 3 узла базы данных, то промежуточный уровень программного обеспечения сети приложения сообщает, что все серверы базы данных недоступны (На это решение могло повлиять тот факт, что если вы разрешите приложениям произвольно записывать данные в ваши реплики mnesia, то очень вероятно, что возникнут несогласованные ошибки базы данных в случае, если ваши узлы mnesia потеряют сетевое соединение друг с другом, но записи выполняются для каждого из них.другими приложениями Erlang. Если вы решите иметь master_nodes, то вы рискуете потерять данные).Итак, по поведению вы заставляете DB Side A быть хозяином.Это приводит к тому, что другие узлы базы данных простаивают все время, пока DB Side A запущен и работает, и, таким образом, столько запросов, сколько на стороне удара A, и он не выключается, ни один запрос не будет попадать на сторону B и центр восстановления вообще.
Mnesia при запуске, как правило, должна видеть, что все задействованные узлы работают (mnesia должна работать на всех задействованных узлах), чтобы она могла выполнять свои переговоры и проверки согласованности. Это означает, что если mnesia отключается на всех узлах, mnesia должна быть запущена на всех узлах, прежде чем она сможет полностью инициализировать и загрузить таблицы. Еще хуже, если Erlang VM умирает вместе с Mnesia на удаленном сайте. Ну, несколько твиков и скриптов тут и там могут помочь перезапустить всю виртуальную машину плюс намеченные приложения, если она выйдет из строя.
Короче говоря, позвольте мне перейти к вопросам.
Вопросы
Что бы сделал администратор базы данных, если mnesia генерирует события inconsistent_database, starting to run database behind a partitioned network в ситуации, когда установка mnesia master node нежелательна (из-за страха потери данных)?
Каковы последствия события mnesia inconsistent_database, starting to run database behind a partitioned network в отношении моего заявления? Что если я не отреагирую на это событие и не позволю вещам продолжаться, как они есть? Я теряю данные?
В больших кластерах mnesia, что можно сделать, если Mnesia отключается вместе с Erlang VM на удаленном сайте? Есть ли какие-либо известные хорошие методы автоматической обработки этой ситуации?
В тех случаях, когда один или два узла недоступны из-за сетевых проблем или сбоев, а mnesia на выжившем узле сообщает, что данный файл не существует, особенно в тех случаях, когда у вас indexes. Итак, как будет работать мое приложение во время выполнения, если некоторые реплики выйдут из строя? Вы бы посоветовали мне иметь главный узел в кластере mnesia?
Когда вы отвечаете на вопросы выше, вы также можете выделить макет, описанный в начале, независимо от того, будет ли он обеспечивать доступность. Вы можете поделиться своим личным опытом работы с фрагментированными и реплицированными базами данных mnesia в производстве. Что касается связанного (цитируемого) вопроса в самом начале этого текста, предоставьте альтернативные параметры, которые могут обеспечить большую надежность при создании базы данных, например, с точки зрения количества фрагментов, зависимостей операционной системы, размера пула узлов, типов копирования таблиц. и т. д.