Следуя решениям вопроса, который я недавно задавал о фрагментации мнений, у меня все еще есть ряд проблем. Рассмотрим следующий сценарий (вопрос, который я задаю, основан на том, что следует ниже):
У вас есть управляемое данными корпоративное приложение, которое должно быть высокодоступным
в пределах предприятия. Если внутренний источник информации по какой-либо причине не работает,
корпоративные приложения должны переключиться на получение данных из центра восстановления
, который находится вне офиса (удаленно).Вы решили реплицировать базу данных на два узла внутри предприятия
(называемые сторона БД 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
Mnesia. To achieve this, you create say: '[email protected]',
'[email protected]' and finally, '[email protected]'
Now, at Table creation, you would want to have your mnesia tables fragmented. So you decide on the following parameters:
n_disc_only_copies =:= number of nodes involved in the pool =:= 3 Reason: You are following the documentation that this parameter regulates howAll your tables are then created based on the following arrangement
many disc_only_copies replicas that each fragment should have.
So you want each table to have each of its fragments on each mnesia Node.
node_pool =:= all nodes involved =:= ['[email protected]',
'[email protected]',
'[email protected]']
Nodes = [
'[email protected]',
'[email protected]',
'[email protected]'
],
No_of_fragments = 16,
{atomic,ok} = mnesia:create_table(TABLE_NAME,[
{frag_properties,[
{node_pool,Nodes},
{n_fragments,No_of_fragments},
{n_disc_only_copies,length(Nodes)}]
},
{index,[]},
{attributes,record_info(fields,RECORD_NAME_HERE)}]
),
NOTE: In the syntax above, RECORD_NAME_HERE cannot be a variable in reality since records must be known at compile time with Erlang.
From the installation, you see that for each table, every fragment, say, table_name_frag2, appears on every Node's file system. Проблемы и возникающие вопросы:
После того, как вы выполнили все, что указано выше, ваш первый запуск базы данных прошел нормально, так как 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 умирает вместе с Mnesia на удаленном сайте. Что ж, несколько настроек и сценариев здесь и там могут помочь перезапустить всю виртуальную машину вместе с предполагаемыми приложениями, если она выйдет из строя.
Короче говоря, позвольте мне перейти к вопросам.
Вопросы:
Что должен сделать администратор базы данных, если mnesia генерирует события
inconsistent_database, starting to run database behind a partitioned networkв ситуации, когда установкаmnesia master nodeнежелательна (из-за опасения потери данных)?Каковы последствия события мнезии
inconsistent_database, starting to run database behind a partitioned networkв отношении моего заявления? Что, если я не отреагирую на это событие и оставлю все как есть? Я теряю данные?Что делать в больших кластерах mnesia, если Mnesia выйдет из строя вместе с виртуальной машиной Erlang на удаленном сайте? Существуют ли какие-либо известные хорошие методы автоматической обработки этой ситуации?
Бывают случаи, когда один или два узла недоступны из-за сетевых проблем или сбоев, а мнения на уцелевшем узле сообщает, что данный файл не существует, особенно в тех случаях, когда у вас есть
indexes. Итак, во время выполнения, как поведет себя мое приложение, если некоторые реплики перестанут работать? Не могли бы вы посоветовать мне иметь главный узел в кластере мнезии?
Когда вы ответите на вопросы выше, вы также можете выделить на макете, описанном в начале, будет ли он обеспечивать доступность. Вы можете поделиться своим личным опытом работы с фрагментированными и реплицированными базами данных mnesia в производственной среде. Ссылаясь на связанный (цитируемый) вопрос в самом начале этого текста, предоставьте альтернативные настройки, которые могли бы обеспечить большую надежность при создании базы данных, скажем, с точки зрения количества фрагментов, зависимостей операционной системы, размера пула узлов, типов копий таблиц. , и т.д.
