Я нахожусь на завершающей стадии настройки службы, доступной из четырех глобальных местоположений (планирую добавить больше позже). Я буду запускать серверы на Ubuntu 12.04 с MariaDB. Моя первоначальная мысль заключалась в том, чтобы создать серверы, которые будут работать независимо друг от друга с 4 отдельными базами данных и жить с ограничением, что пользователи смогут входить только на тот сервер, на котором они были первоначально зарегистрированы.
Однако я только что столкнулся с эта статья, которая заставила меня задуматься ...
Судя по тому, что я читал, если я настрою кластер Galera с репликацией мастер-мастер, как предложено в статье, я смогу перенести роскошь одной большой базы данных, которая будет постоянно доступна на всех четырех серверах. Я понял (и надеюсь), что при правильной настройке кластера и его хорошем функционировании мне почти ничего не нужно делать в моем PHP-коде (четыре экземпляра MariaDB будут иметь одного и того же пользователя для доступа к базе данных) - даже не изменять строку подключения PDO .
Однако это звучит слишком хорошо, чтобы быть правдой. Мои вопросы:
- Есть ли здесь другие проблемы, которые могут привести к осложнениям?
- Нужно ли в любом случае изменять строки подключения PHP PDO?
- Помогает ли тот факт, что мое приложение уже структурировано для обеспечения абсолютно нулевой вероятности того, что два сервера попытаются одновременно записать одну и ту же строку?
- И, наконец, прочитав из документации MariaDB, не будет работать с механизмом хранения TokuDB?
- Есть ли способ специально остановить репликацию выбранной таблицы? Могу ли я на самом деле использовать ограничение «только InnoDB / XtraDB» и использовать другой механизм хранения для таблицы, которую я не хочу реплицировать?
2 ответа
Есть ли здесь другие проблемы, которые могут привести к осложнениям?
Вам следует помнить о некоторых известных ограничениях. Как правило, с кластерами в идеале вы должны иметь нечетное количество узлов, чтобы предотвратить условия разделения мозга, но четное число обычно также работает.
Нужно ли в любом случае изменять строки подключения PHP PDO?
Нет. Ваши существующие строки подключения должны работать.
Помогает ли тот факт, что мое приложение уже структурировано для обеспечения абсолютно нулевой вероятности того, что два сервера попытаются одновременно записать одну и ту же строку?
Ознакомьтесь с известными ограничениями и убедитесь, что ваше приложение по-прежнему их поддерживает. Если вы используете именованные блокировки, вам нужно изменить свое приложение.
И, наконец, читая документы MariaDB, это не будет работать с механизмом хранения TokuDB?
Поддержка TokuDB была добавлена в недавний кластерный дистрибутив galera. Я использовал некоторые из них, и они реплицируются точно так же, как InnoDB, но я бы не стал на них полагаться, поскольку это новинка в сборке кластера galera.
Есть ли способ специально остановить репликацию выбранной таблицы? Могу ли я на самом деле использовать ограничение «только InnoDB / XtraDB» и использовать другой механизм хранения для таблицы, которую я не хочу реплицировать?
Я слышал, как многие спрашивают, могут ли они исключать таблицы или базы данных из репликации, но я до сих пор не слышал веской причины, почему. Репликация Galera обеспечивает высокую доступность, дешево и просто, поэтому, даже если некоторые таблицы не важны, я не могу найти реальной причины не реплицировать данные. При этом у вас могут быть данные, которые не реплицируются с помощью MyISAM / Aria.
Я использую MariaDB с galera в нескольких проектах среднего размера, и это лучшее решение, которое я нашел для высокой доступности, а также дает преимущества в производительности. Другие решения обычно дороги или незрелы. Вам следует подумать о настройке прокси-сервера для подключения к серверам баз данных, таким как HA Proxy, mysql-proxy или glbd (которые я использую), чтобы обеспечить лучшую избыточность и балансировку соединений для повышения производительности.
В ответ на комментарий DroidOS ниже:
Каждая запись в кластере должна быть согласована каждым узлом, поэтому любая задержка между узлами добавляется к каждой записи. Таким образом, в основном, каждая запись будет иметь наибольшее время прохождения туда и обратно между записывающим сервером и другими добавленными к нему узлами.
Нет. Репликация Galera - это все или ничего во всем кластере. Если какой-либо узел имеет проблемы с записью данных, что может произойти, если таблица не имеет первичного ключа, узел корректно убьет себя, поскольку не может гарантировать, что его данные согласованы с остальной частью кластера. Если это произойдет, остальная часть кластера продолжит нормально работать. Если есть проблема с сетью, если один из сегментов имеет кворум, он продолжит нормально работать. Любые сегменты без кворума будут ждать, пока другие узлы получат кворум, но не будут принимать запросы. Благодаря такому поведению вы можете быть уверены, что любой узел, который вы можете запрашивать, совместим с остальной частью кластера.
Учитывая, что это оказался такой популярный вопрос, я подумал, что должен добавить дополнительный ответ в виде комментария для всех, кто с ним сталкивается.
Большой проблемой синхронной репликации является задержка, вызванная процессом. Безусловно, будут моменты, когда потребуется синхронная репликация, а задержкой придется управлять, а затем жить с ней. Однако, поразмыслив, как я, вы могли бы понять, что с ленивой репликацией можно жить. Существуют коммерческие решения, доставляющие это, хотя и за изрядную плату. У вас также есть возможность создать собственное решение - проще, чем вы думаете.
Похожие вопросы
Связанные вопросы
Новые вопросы
php
PHP — это открытый, мультипарадигмальный, динамически типизированный и интерпретируемый язык сценариев, изначально разработанный для веб-разработки на стороне сервера. Используйте этот тег для вопросов о программировании на языке PHP.