21.9.6.5. Понятия

Copyright 1997-2012 PHP Documentation Group.

mysqlnd плагин репликации и выравнивания нагрузки реализуется как расширение PHP. Это пишется в C и работает под капотом PHP. Во время запуска интерпретатора PHP, в модуле init фаза механизма PHP, это регистрируется как mysqlnd плагин, чтобы заменить выбранные mysqlnd методы C.

Во времени выполнения PHP это осматривает запросы, отправленные от mysqlnd (PHP) к серверу MySQL. Если запрос будет распознан как только для чтения, то он будет отправлен одному из сконфигурированных ведомых серверов. Операторы считают только для чтения если они любой запуск с SELECT, подсказка SQL /*ms=slave*/ или ведомое устройство было выбрано для того, чтобы выполнить предыдущий запрос, и запрос, запущенный с подсказки SQL /*ms=last_used*/. Во всех других случаях запрос будет отправлен главному серверу репликации MySQL.

Для лучшей мобильности приложения должны использовать MYSQLND_MS_MASTER_SWITCH , MYSQLND_MS_SLAVE_SWITCH , и MYSQLND_MS_LAST_USED_SWITCH предопределенные mysqlnd_ms константы, вместо их литеральных значений, такой как /*ms=slave*/.

Плагин обрабатывает открытие и закрытие соединений с базой данных и к основным и к ведомым серверам. С точки зрения приложения продолжает быть только один дескриптор соединения. Однако, внутренне, этот общедоступный дескриптор соединения представляет пул сетевых соединений, которыми управляет плагин. Плагин проксирует запросы к главному серверу, и к ведомым устройствам, используя многократные соединения.

У соединений с базой данных есть состояние, состоящее из, например, состояние транзакции, настройки транзакции, настройки набора символов, и временные таблицы. Плагин попытается поддержать то же самое состояние среди всех внутренних соединений, всякий раз, когда это может быть сделано автоматическим и прозрачным способом. В случаях, где не легко возможно поддержать состояние среди всех соединений, такой, используя BEGIN TRANSACTION, плагин предоставляет пользователю право обрабатывать.

Copyright 1997-2012 PHP Documentation Group.

Плагин репликации и выравнивания нагрузки изменяет семантику дескриптора соединения MySQL PHP. Существующий API расширений MySQL PHP (mysqli, mysql, и PDO_MYSQL) не изменяется в способе, которым функции добавляются или удаляются. Но их поведение изменяется при использовании плагина. Существующие приложения не должны быть адаптированы к новому API, но они, возможно, должны быть изменены из-за изменений поведения.

Плагин повреждается один за другим отношение между mysqli, mysql, и дескриптором соединения PDO_MYSQL и соединением сети MySQL. И mysqli, mysql, и дескриптор соединения PDO_MYSQL представляют локальный пул соединений со сконфигурированным ведущим устройством репликации MySQL и ведомыми серверами репликации MySQL. Плагин перенаправляет запросы к основным и ведомым серверам. В некоторый момент вовремя один и тот же дескриптор соединения PHP может указать на главный сервер MySQL. Позже, это может указать на один из ведомых серверов или тем не менее ведущего устройства. Управление и замена сетевого соединения, на которое ссылается дескриптор соединения MySQL PHP, не являются прозрачной работой.

У каждого соединения MySQL есть состояние. Состояние соединений в пуле соединения плагина может отличаться. Всякий раз, когда сменные переключатели от одного проводного соединения до другого, текущее состояние пользовательского соединения может измениться. Приложения должны знать об этом.

Следующий список показывает то, из чего состоит состояние соединения. Список, возможно, не полон.

Переключатели соединения происходят прямо прежде, чем запросы выполняются. Плагин не переключает текущее соединение, пока следующий оператор не выполняется.

Широковещательно переданные сообщения

Философия плагинов должна выровнять состояние соединений в пуле, только если состояние находится под полным контролем над плагином, или если это необходимо для соображений безопасности. Только несколько действий, которые изменяют состояние соединения, попадают в эту категорию.

Следующее является списком клиентских вызовов библиотеки соединения, которые изменяют состояние, и широковещательно передаются ко всем открытым соединениям в пуле соединения.

Если какой-либо из перечисленных вызовов ниже должен быть выполнен, сменные циклы по всем открытым основным и ведомым соединениям. Цикл продолжается, пока со всеми серверами не связались, и цикл не повреждается, если сервер указывает на отказ. Если возможный, отказ распространит к вызванной пользовательской API-функции, которая может быть обнаружена, в зависимости от которого была инициирована базовая библиотечная функция.

Широковещательная передача и ленивые соединения

Плагин не проксирует или "помнит" все настройки, чтобы применить их на соединениях, открытых в будущем. Это важно, чтобы помнить, используя ленивые соединения. Ленивые соединения являются соединениями, которые не открываются прежде, чем клиент отправляет первое соединение. Использование ленивых соединений является действием плагина значения по умолчанию.

Следующая библиотека соединения вызывает каждое измененное состояние, и их выполнение записывается для более позднего использования, когда ленивые соединения открываются. Это помогает гарантировать, что состояние соединения всех соединений в пуле соединения сопоставимо.

Наборы символов и строковый выход

Из-за использования ленивых соединений, которые являются значением по умолчанию, это может произойти, что приложение пытается выйти из строки для использования в пределах SQL-операторов прежде, чем соединение было установлено. В этом случае строковый выход не возможен. Строковая функция escape не знает, какой набор символов использовать прежде, чем соединение было установлено.

Преодолеть проблему новый параметр конфигурации server_charset был представлен в версии 1.4.0.

Внимание должно быть обращено при выходе из строк с определенным набором символов, но использованием результата на соединении, которое использует различный набор символов. Пожалуйста, отметьте, что PECL/mysqlnd_ms управляет соединениями, и одно соединение уровня приложения представляет пул многократных соединений, что у всех могут быть различные наборы символов значения по умолчанию. Рекомендуется сконфигурировать серверы, включенные, чтобы использовать те же самые наборы символов значения по умолчанию. Параметр конфигурации server_charset действительно помогает с этой ситуацией также. Используя server_charset, плагин установит данный набор символов на всех недавно открытых соединениях.

Copyright 1997-2012 PHP Documentation Group.

Обработка транзакции существенно изменяется. Транзакция SQL является единицей работы, которая выполняется на одном сервере базы данных. Единица работы состоит из одного или более SQL-операторов.

По умолчанию плагин не знает о транзакциях SQL. Плагин может переключить соединения для выравнивания нагрузки в любом моменте времени. Переключатели соединения могут произойти в середине транзакции. Это против природы транзакции SQL. По умолчанию плагин не является безопасной транзакцией.

Любому виду стабилизатора загрузки MySQL нужно подсказать о начинании и конце транзакции. Вывод подсказок может или быть сделан неявно, контролируя вызовы API или используя подсказки SQL. Обе опции поддерживаются плагином, в зависимости от Вашей версии PHP. Контроль API требует PHP 5.4.0 или более новый. Плагин, как любой другой стабилизатор загрузки MySQL, не может обнаружить границы транзакции, основанные на MySQL Client Server Protocol. Таким образом полностью прозрачная транзакция осведомленное выравнивание нагрузки не возможна. Наименее навязчивая опция является контролем API, который требует немногого ни к каким изменениям приложения, в зависимости от Вашего приложения.

Пожалуйста, найдите примеры использования подсказок SQL или API, контролирующего в разделе в качестве примера. Детали позади контроля API, который информирует сменную транзакцию, описываются ниже.

Начиная с PHP 5.4.0, mysqlnd библиотека позволяет этому плагину разделять библиотеку на подклассы C вызов API set_autocommit(), обнаружить состояние autocommit режим.

Расширения MySQL PHP любая проблема запрос (такой как SET AUTOCOMMIT=0|1), или использование mysqlnd вызов библиотеки set_autocommit() управлять autocommit установка. Если расширение использует set_autocommit(), плагин может быть проинформированной транзакцией. Понимание транзакции не может быть достигнуто, используя SQL, чтобы установить режим автоматической фиксации. Библиотечная функция set_autocommit() вызывается mysqli_autocommit и PDO::setAttribute(PDO::ATTR_AUTOCOMMIT) пользовательские вызовы API.

Сменный параметр конфигурации trx_stickiness=master может использоваться, чтобы сделать плагин транзакционным знающий. В этом режиме плагин останавливает выравнивание нагрузки, если автоматическая фиксация становится отключенной, и направляет все операторы к ведущему устройству, пока автоматическая фиксация не включается.

Приложение, которое не хочет устанавливать подсказки SQL для транзакций, но хочет использовать прозрачный API, контролирующий, чтобы избежать изменений приложения, должно удостовериться, что настройки автоматической фиксации изменяются исключительно через перечисленные вызовы API.

API, который базируемое обнаружение границы транзакции было улучшено с PHP 5.5.0 и PECL/mysqlnd_ms 1.5.0, чтобы покрыть не только, призывает mysqli_autocommit но также и mysqli_begin, mysqli_commit и mysqli_rollback.

Copyright 1997-2012 PHP Documentation Group.

Приложения используя PECL/mysqlnd_ms должны реализовать надлежащую обработку ошибок для всех пользовательских вызовов API. И потому что плагин изменяет семантику дескриптора соединения, вызовы API могут возвратить неожиданные ошибки. Используя плагин на дескрипторе соединения, который больше не представляет отдельное сетевое соединение, но пул соединения, код ошибки и сообщение об ошибке будут установлены на дескрипторе соединения всякий раз, когда ошибка происходит на любом из сетевых соединений позади.

Используя ленивые соединения, который является значением по умолчанию, соединения не открываются, пока они не необходимы для выполнения запроса. Поэтому, вызов API выполнения оператора может возвратить ошибку соединения. В примере ниже, ошибка вызывается, пытаясь выполнить оператор на ведомом устройстве. Открытие ведомого соединения перестало работать, потому что сменный конфигурационный файл перечисляет недопустимое имя хоста для ведомого устройства.

{    "myapp": {        "master": {            "master_0": {                "host": "localhost",                "socket": "\/tmp\/mysql.sock"            }        },        "slave": {            "slave_0": {                "host": "invalid_host_name",            }        },        "lazy_connections": 1    }}

Явная активация ленивых соединений в демонстрационной цели только.

<?php$mysqli = new mysqli("myapp", "username", "password", "database");if (mysqli_connect_errno())  /* Of course, your error handling is nicer... */  die(sprintf("[%d] %s\n", mysqli_connect_errno(), mysqli_connect_error()));/* Connection 1, connection bound SQL user variable, no SELECT thus run on master */if (!$mysqli->query("SET @myrole='master'")) { printf("[%d] %s\n", $mysqli->errno, $mysqli->error);}/* Connection 2, run on slave because SELECT, provoke connection error */if (!($res = $mysqli->query("SELECT @myrole AS _role"))) { printf("[%d] %s\n", $mysqli->errno, $mysqli->error);} else { $row = $res->fetch_assoc(); $res->close(); printf("@myrole = '%s'\n", $row['_role']);}$mysqli->close();?>    

PHP Warning:  mysqli::query(): php_network_getaddresses: getaddrinfo failed: Name or service not known in %s on line %dPHP Warning:  mysqli::query(): [2002] php_network_getaddresses: getaddrinfo failed: Name or service not known (trying to connect via tcp://invalid_host_name:3306) in %s on line %d[2002] php_network_getaddresses: getaddrinfo failed: Name or service not known

Приложения, как ожидают, обработают возможные ошибки соединения, реализовывая надлежащую обработку ошибок.

В зависимости от варианта использования приложения могут хотеть обработать ошибки соединения по-другому от других ошибок. Типичные ошибки соединения 2002 (CR_CONNECTION_ERROR) - Can't connect to local MySQL server through socket '%s' (%d), 2003 (CR_CONN_HOST_ERROR) - Can't connect to MySQL server on '%s' (%d) и 2005 (CR_UNKNOWN_HOST) - Unknown MySQL server host '%s' (%d). Например, приложение может протестировать на коды ошибки и вручную выполнить сбой. Философия плагинов не должна предложить автоматический сбой вне основного сбоя, потому что сбой не является прозрачной работой.

{    "myapp": {        "master": {            "master_0": {                "host": "localhost"            }        },        "slave": {            "slave_0": {                "host": "invalid_host_name"            },            "slave_1": {                "host": "192.168.78.136"            }        },        "lazy_connections": 1,        "filters": {            "roundrobin": [            ]        }    }}

Явно активирование ленивых соединений делается в демонстрационных целях, как круговое выравнивание нагрузки в противоположность значению по умолчанию random once ввести.

<?php$mysqli = new mysqli("myapp", "username", "password", "database");if (mysqli_connect_errno())  /* Of course, your error handling is nicer... */  die(sprintf("[%d] %s\n", mysqli_connect_errno(), mysqli_connect_error()));/* Connection 1, connection bound SQL user variable, no SELECT thus run on master */if (!$mysqli->query("SET @myrole='master'")) { printf("[%d] %s\n", $mysqli->errno, $mysqli->error);}/* Connection 2, first slave */$res = $mysqli->query("SELECT VERSION() AS _version");/* Hackish manual fail over */if (2002 == $mysqli->errno || 2003 == $mysqli->errno || 2004 == $mysqli->errno) {  /* Connection 3, first slave connection failed, trying next slave */  $res = $mysqli->query("SELECT VERSION() AS _version");}if (!$res) {  printf("ERROR, [%d] '%s'\n", $mysqli->errno, $mysqli->error);} else { /* Error messages are taken from connection 3, thus no error */ printf("SUCCESS, [%d] '%s'\n", $mysqli->errno, $mysqli->error); $row = $res->fetch_assoc(); $res->close(); printf("version = %s\n", $row['_version']);}$mysqli->close();?>    

[1045] Access denied for user 'username'@'localhost' (using password: YES)PHP Warning:  mysqli::query(): php_network_getaddresses: getaddrinfo failed: Name or service not known in %s on line %dPHP Warning:  mysqli::query(): [2002] php_network_getaddresses: getaddrinfo failed: Name or service not known (trying to connect via tcp://invalid_host_name:3306) in %s on line %dSUCCESS, [0] ''version = 5.6.2-m5-log

В некоторых случаях, возможно, не легко возможно получить все ошибки, которые происходят на всех сетевых соединениях через дескриптор соединения. Например, давайте предполагать, что дескриптор соединения представляет пул трех открытых соединений. Одно соединение с ведущим устройством и два соединения с ведомыми устройствами. Приложение изменяет текущую базу данных, используя пользовательский вызов API mysqli_select_db, который тогда вызывает mysqlnd библиотечную функцию, чтобы изменить схемы. mysqlnd_ms контролирует функцию, и пытается изменить текущую базу данных на всех соединениях, чтобы согласовать их состояние. Теперь, предположите, что ведущее устройство преуспевает в том, чтобы изменить базу данных, и оба ведомых сбоя. На начальную ошибку от первого ведомого устройства плагин установит соответствующую ошибку на дескрипторе соединения. То же самое делается, когда второе ведомое устройство не в состоянии изменить базу данных. Сообщение об ошибке от первого ведомого устройства теряется.

Такие случаи могут быть отлажены любой проверкой ошибки типа E_WARNING (см. выше), или, если никакая другая опция, исследование отладки mysqlnd_ms и не прослеживают журнал.

Copyright 1997-2012 PHP Documentation Group.

Некоторые кластеры распределенной базы данных используют случайные ошибки. Случайная ошибка является нерегулярной ошибкой, которая, вероятно, скоро исчезнет. По определению безопасно для клиента проигнорировать случайную ошибку и повторить отказавшую работу на том же самом сервере базы данных. Повторная попытка свободна от побочных эффектов. Клиенты не вынуждаются прервать свою работу или сразу перестать работать к другому серверу базы данных. Они могут ввести цикл повторной попытки прежде, чтобы ожидать ошибки исчезнуть перед отказыванием от сервера базы данных. Случайные ошибки могут быть замечены, например, при использовании MySQL Cluster. Но они не связываются ни с каким определенным решением для кластеризации по существу.

PECL/mysqlnd_ms может выполнить автоматический цикл повторной попытки в случае случайной ошибки. Это увеличивает прозрачность распределения и таким образом облегчает перемещать приложение, работающее на единственном сервере базы данных, чтобы работать на кластере серверов баз данных, не имея необходимость изменять источник приложения.

Автоматический цикл повторной попытки повторит требуемую работу до пользователя конфигурируемое число раз и пауза между попытками для конфигурируемого количества времени. Если ошибка исчезнет во время цикла, то приложение никогда не будет видеть это. В противном случае ошибка передается приложению для того, чтобы обработать.

В примере ниже двойной ключевой ошибки побуждается заставить плагин повторить запрос сбоя два раза прежде, чем ошибку передадут к приложению. Между двумя попытками плагин спит для 100 миллисекунд.

mysqlnd_ms.enable=1mysqlnd_ms.collect_statistics=1    

{    "myapp": {        "master": {            "master_0": {                "host": "localhost"            }        },        "slave": {            "slave_0": {                "host": "192.168.78.136",                "port": "3306"            }       },       "transient_error": {          "mysql_error_codes": [            1062          ],          "max_retries": 2,          "usleep_retry": 100       }    }}

<?php$mysqli = new mysqli("myapp", "username", "password", "database");if (mysqli_connect_errno())  /* Of course, your error handling is nicer... */  die(sprintf("[%d] %s\n", mysqli_connect_errno(), mysqli_connect_error()));if (!$mysqli->query("DROP TABLE IF EXISTS test") ||    !$mysqli->query("CREATE TABLE test(id INT PRIMARY KEY)") ||    !$mysqli->query("INSERT INTO test(id) VALUES (1))")) {  printf("[%d] %s\n", $mysqli->errno, $mysqli->error);}/* Retry loop is completely transparent. Checking statistics is the only way to know about implicit retries */$stats = mysqlnd_ms_get_stats();printf("Transient error retries before error: %d\n", $stats['transient_error_retries']);/* Provoking duplicate key error to see statistics change */if (!$mysqli->query("INSERT INTO test(id) VALUES (1))")) {  printf("[%d] %s\n", $mysqli->errno, $mysqli->error);}$stats = mysqlnd_ms_get_stats();printf("Transient error retries after error: %d\n", $stats['transient_error_retries']);$mysqli->close();?>    

Transient error retries before error: 0[1062] Duplicate entry '1' for key 'PRIMARY'Transient error retries before error: 2

Поскольку выполнение цикла повторной попытки прозрачно с пользовательской точки зрения, пример проверяет статистику, обеспеченную плагином, чтобы узнать об этом.

Поскольку пример показывает, плагин может быть проинструктирован, чтобы рассмотреть любой ошибочный переходный процесс независимо от ошибочной семантики серверов баз данных. У единственной ошибки, которую сервер MySQL запаса считает временным, есть код ошибки 1297 . Конфигурируя другие коды ошибки, но 1297 удостоверьтесь, что Ваша конфигурация отражает семантику Ваших кодов ошибки кластеров.

Следующие mysqlnd C вызовы API контролируются плагином, чтобы проверить на случайные ошибки: query(), change_user(), select_db(), set_charset(), set_server_option() prepare(), execute(), set_autocommit(), tx_begin(), tx_commit(), tx_rollback(), tx_commit_or_rollback(). У соответствующих пользовательских вызовов API есть аналогичные имена.

Максимальное время плагин может спать во время цикла повторной попытки, зависит от рассматриваемой функции. Цикл повторной попытки для query(), prepare() или execute() будет спать для до max_retries * usleep_retry миллисекунды.

Однако, функции, которые управляют состоянием соединения, диспетчеризируются всем всем соединениям. Настройки цикла повторной попытки применяются к каждому соединению, на котором должна быть выполнена команда. Таким образом такая функция может прервать выполнение программы для дольше чем функция, которая выполняется на одном сервере только. Например, set_autocommit() диспетчеризируется соединениям и может спать до (max_retries * usleep_retry) * number_of_open_connections) миллисекунды. Пожалуйста, помните это, устанавливая долгие времена сна и большие числа повторной попытки. Используя настройки по умолчанию max_retries=1, usleep_retry=100 и lazy_connections=1 маловероятно, что Вы будете когда-либо видеть задержку больше чем 1 секунды.

Copyright 1997-2012 PHP Documentation Group.

По умолчанию соединение failover обработка оставляют пользователю. Приложение ответственно за проверку возвращаемых значений функций базы данных, которые оно вызывает и реагировать на возможные ошибки. Если, например, плагин распознает, что запрос как, что запрос только для чтения отправляется ведомым серверам, и ведомый сервер, выбранный плагином, не доступен, то плагин повысит ошибку после не выполнения оператора.

Значение по умолчанию: руководство failover

Это до приложения, чтобы обработать ошибку и, если требующийся, переиздать запрос, чтобы инициировать выбор другого ведомого сервера для выполнения оператора. Плагин не предпримет попыток к failover автоматически, потому что плагин не может гарантировать, что автоматический failover не будет изменять состояние соединения. Например, приложение, возможно, выпустило запрос, который зависит от пользовательских переменных SQL, которые связываются с определенным соединением. Такой запрос мог бы возвратить неправильные результаты, если плагин переключит соединение неявно как часть автоматического failover. Чтобы гарантировать корректные результаты, приложение должно заботиться о failover, и восстановить необходимое состояние соединения. Поэтому, по умолчанию, никакой автоматический failover не выполняется плагином.

Пользователь, который не изменяет состояние соединения после открытия соединения, может активировать автоматический failover. Пожалуйста, отметьте, что автоматическая failover логика ограничивается попытками подключения. Автоматический failover не используется для уже установленных соединений. Нет никакого способа дать плагину команду делать попытку failover на соединении, которое было соединено с MySQL уже в прошлом.

Автоматический failover

failover политика конфигурируется в конфигурационном файле плагинов, при использовании failover конфигурационной директивы.

Автоматический и тихий failover может быть включен через failover конфигурационную директиву. Автоматический failover может или быть сконфигурирован, чтобы судить точно одно ведущее устройство после ведомого отказа или, альтернативно, цикл по ведомым устройствам и ведущим устройствам прежде, чем возвратить ошибку пользователю. Число попыток подключения может быть ограничено и перестало работать, узлы могут быть исключены из будущих попыток выравнивания нагрузки. Ограничение числа повторений и запоминание отказавших узлов считают экспериментальными функциями, будучи разумной конюшней. Синтаксис и семантика могут измениться в будущих версиях.

Пожалуйста, отметьте, начиная с версии 1.5.0 автоматический failover отключается для продолжительности транзакции, если неподвижность транзакции включается, и границы транзакции были обнаружены. Плагин не будет переключать соединения для продолжительности транзакции. Это не будет также выполнять автоматический и тихий failover. Вместо этого ошибка будет брошена. Это тогда оставляют пользователю обработать отказ транзакции. Пожалуйста, проверьте, trx_stickiness документация, как сделать это.

Основное руководство failover пример обеспечивается в пределах раздела обработки ошибок.

Резервные серверы

Используя взвешенное выравнивание нагрузки, представленное в PECL/mysqlnd 1.4.0, возможно сконфигурировать резервные серверы, которые редко используются во время нормального функционирования. Резервный сервер, который прежде всего используется в качестве резервного устройства худшего случая failover цель, может быть присвоен очень низкий вес/приоритет относительно всех других серверов. Пока все серверы в порядке, большинство рабочей нагрузки присваивается серверам, у которых есть значения веса высоты. Немного запросов будут направлены к резервной системе, у которой есть очень низкое значение веса.

На отказ серверов с высоким приоритетом Вы можете все еще failover к резервному устройству, которому дали низкий приоритет выравнивания нагрузки, присваивая низкий вес ему. Failover может быть некоторыми вручную или автоматически. Если сделано автоматически, можно хотеть объединить это с remember_failed опция.

В этой точке не возможно дать стабилизатору загрузки команду не направлять запросы вообще к резервному устройству. Это, возможно, не большая часть ограничения, учитывая, что самый высокий вес, который можно присвоить серверу, 65535. Учитывая два ведомых устройства, из которых должен действовать как резервное устройство и был присвоен вес 1, резервное устройство должно будет обработать далеко меньше чем один процент полной рабочей нагрузки.

Failover и основная копия

Пожалуйста, отметьте, используя основной кластер копии, такой как MySQL Replication, трудно сделать соединение failover в случае основного отказа. В любое время есть только одно ведущее устройство в кластере для данного набора данных. Ведущее устройство является единственной точкой отказа. Если ведущее устройство перестало работать, у клиентов нет никакой цели, чтобы перестать работать по запросам записи. В случае основного отключения электричества администратор базы данных должен заботиться о ситуации и обновить клиентские конфигурации в случае необходимости.

Copyright 1997-2012 PHP Documentation Group.

Четыре стратегии выравнивания нагрузки поддерживаются, чтобы распределить операторы по сконфигурированным ведомым серверам MySQL:

Политика выравнивания нагрузки конфигурируется в конфигурационном файле плагинов, используя случайное, круговое, и пользователь фильтры.

Серверы могут быть расположены по приоритетам, присваивая вес. Сервер, которому дали вес два, получит вдвое больше запросов как сервер, которому дали вес значения по умолчанию одного. Установление приоритетов может быть удобным в неоднородных средах. Например, можно хотеть присвоить больше запросов мощной машине чем к менее мощному. Или, Вы, возможно, сконфигурировали серверы, которые близки или далеки от клиента, таким образом представляют различные задержки.

Copyright 1997-2012 PHP Documentation Group.

Плагин выполняет операторы только для чтения на сконфигурированных ведомых устройствах MySQL, и все другие запросы на ведущем устройстве MySQL. Операторы считают только для чтения если они любой запуск с SELECT, подсказка SQL /*ms=slave*/, или если ведомое устройство было выбрано для того, чтобы выполнить предыдущий запрос, и запрос запускается с подсказки SQL /*ms=last_used*/. Во всех других случаях запрос будет отправлен главному серверу репликации MySQL. Рекомендуется использовать константы MYSQLND_MS_SLAVE_SWITCH , MYSQLND_MS_MASTER_SWITCH и MYSQLND_MS_LAST_USED_SWITCH вместо /*ms=slave*/. См. также список mysqlnd_ms констант.

Подсказки SQL являются специальным видом стандартных совместимых комментариев SQL. Плагин действительно проверяет каждый оператор на определенные подсказки SQL. Подсказки SQL описываются в пределах mysqlnd_ms документации констант, константы, которые экспортируются расширением. Другие системы, связанные с обработкой оператора, такие как сервер MySQL, брандмауэры SQL, и прокси SQL, незатронуты подсказками SQL, потому что те системы разрабатываются, чтобы проигнорировать комментарии SQL.

Встроенный разделитель чтения-записи может быть заменен определяемым пользователем фильтром, видеть также пользовательскую документацию фильтра.

Определяемый пользователем разделитель чтения-записи может запросить встроенную логику отправить оператор определенному расположению, вызывая mysqlnd_ms_is_select.

Copyright 1997-2012 PHP Documentation Group.

фильтры. Приложения PHP, которые реализуют кластер репликации MySQL, должны сначала идентифицировать группу серверов в кластере, который мог выполнить оператор прежде, чем оператор будет выполнен одним из кандидатов. Другими словами: определенный список серверов должен фильтроваться, пока только один сервер не доступен.

Процесс фильтрации может включать использование того или большего количества фильтров, и фильтры могут быть объединены в цепочку. И они выполняются в порядке, они определяются в конфигурационном файле плагинов.

Доступные фильтры:

random фильтруйте реализует 'случайное' и 'случайный однажды' политики выравнивания нагрузки. 'Круговое' выравнивание нагрузки может быть сконфигурировано через roundrobin фильтр. Установка 'определяемого пользователем обратного вызова' для выбора сервера возможна с user фильтр. quality_of_service фильтр находит, что узлы кластера, способные к поставке определенной службы, например, ", читают Ваши записи" или, не изолируя больше секунд позади ведущего устройства чем позволенный.

Фильтры могут принять, что параметры изменяют свое поведение. random фильтр принимает дополнительное sticky параметр. Если установлено в истину, фильтр изменяет выравнивание нагрузки от случайного до случайного однажды. Должны быть выполнены случайные выборы случайный сервер каждый раз оператор. Случайный однажды выборы случайный сервер, когда первый оператор должен быть выполнен и использует тот же самый сервер для остальной части запроса PHP.

Одна из самой большой силы понятия фильтра является возможностью объединить фильтры в цепочку. Эта сила сразу не становится видимой потому что tje random, roundrobin и user фильтры, как предполагается, выводят не больше, чем один сервер. Если фильтр уменьшает список кандидатов для того, чтобы выполнить оператор только к одному серверу, имеет небольшой смысл использовать тот один сервер как входной для другого фильтра для дальнейшего сокращения списка кандидатов.

Последовательность фильтра в качестве примера, которая перестанет работать:

Существует второй тип фильтра: много фильтр. Много фильтр испускает нуль, один или многократные серверы после обработки. quality_of_service фильтр является примером. Если качество обслуживания требуемые наборы, верхний предел для ведомой задержки и больше чем одного ведомого устройства отстает от меньше чем позволенное число секунд, фильтр, возвращает больше чем один узел кластера. Много фильтр должен сопровождаться другим, чтобы далее уменьшить список кандидатов для выполнения оператора, пока кандидат не находится.

Последовательность фильтра с quality_of_service много фильтр следовал фильтром выравнивания нагрузки.

Последовательность фильтра не должна закончиться много фильтром. Пытаясь использовать последовательность фильтра, которая заканчивается много фильтром, как который плагин может испустить предупреждение (mysqlnd_ms) Error in configuration. Last filter is multi filter. Needs to be non-multi one. Stopping in %s on line %d. Кроме того соответствующая ошибка на дескрипторе соединения может быть установлена.

Copyright 1997-2012 PHP Documentation Group.

Плагин может использоваться с различными видами кластеров базы данных MySQL. Различные кластеры могут поставить разные уровни службы к приложениям. Уровни обслуживания могут быть сгруппированы по условию уровни непротиворечивости, которые могут быть достигнуты. Плагин знает о:

Завися, как кластер используется, может быть возможно достигнуть более высоких уровней обслуживания чем значение по умолчанию один. Например, чтение от асинхронного ведомого устройства репликации MySQL возможно непротиворечивый. Таким образом можно сказать, что уровень непротиворечивости значения по умолчанию кластера репликации MySQL является возможной непротиворечивостью. Однако, если ведущее устройство только используется клиентом для чтения и записи во время сеанса, непротиворечивость сеанса (читайте, Ваши записи) дается. PECL mysqlnd 1.2.0 кратких обзора детали выбора соответствующего узла для любого из вышеупомянутых уровней обслуживания от пользователя.

Уровни обслуживания могут быть установлены посредством квалифицирования из службы, просачиваются конфигурационный файл плагинов и во времени выполнения, используя функцию mysqlnd_ms_set_qos.

Плагин определяет различные уровни обслуживания следующим образом.

Возможная непротиворечивость является услугой значения по умолчанию, предоставленной асинхронным кластером, таким как классическая репликация MySQL. Операция чтения, выполняемая на произвольном узле, может или, возможно, не возвращает устаревшие данные. Представление приложений данных возможно непротиворечивый.

Непротиворечивость сеанса дается, если клиент может всегда читать ее собственные записи. Асинхронный кластер репликации MySQL может поставить непротиворечивость сеанса, если клиенты всегда используют ведущее устройство после первой записи или никогда не запрашивают ведомое устройство, которое еще не тиражировало клиентскую операцию записи.

Понимание плагинов непротиворечивости strong - то, что все клиенты всегда видят фиксировавшие записи всех других клиентов. Это - значение по умолчанию при использовании MySQL Cluster или любого другого кластера, предлагающего синхронное распределение данных.

Параметры уровня обслуживания

Возможная непротиворечивость и уровень обслуживания непротиворечивости сеанса принимают параметры.

Возможная непротиворечивость является услугой, предоставленной классической репликацией MySQL. По умолчанию все узлы имеют право на запросы чтения. Дополнительное age параметр может быть дан, чтобы отфильтровать узлы, которые изолируют больше чем определенное число секунд позади ведущего устройства. Плагин использует SHOW SLAVE STATUS измерять задержку. Пожалуйста, см. справочник MySQL, чтобы узнать о точности и надежности SHOW SLAVE STATUS команда.

Непротиворечивость сеанса (читает Ваши записи) принимает дополнительное GTID параметр, чтобы рассмотреть чтение не только от ведущего устройства, но также и от ведомых устройств, которые уже тиражировали определенную запись, описанную ее идентификатором транзакции. Таким образом, при использовании асинхронной репликации MySQL, читайте, запросы могут быть загрузкой, сбалансированной по ведомым устройствам, все еще гарантируя непротиворечивость сеанса.

Последний требует использования клиентской глобальной инжекции идентификатора транзакции.

Преимущества нового подхода

Новый подход заменяет использование подсказок SQL и параметра конфигурации master_on_write в некотором отношении. Если приложение, работающее сверху асинхронного кластера репликации MySQL, не может принять устаревшие данные для определенных чтений, легче сказать плагину выбирать соответствующие узлы, чем добавление префикса всех рассматриваемых операторов чтения с SQL подсказывает, чтобы осуществить использование ведущего устройства. Кроме того плагин может быть в состоянии использовать выбранные ведомые устройства для того, чтобы читать.

master_on_write параметр конфигурации заставляет плагин использовать ведущее устройство после первой записи (непротиворечивость сеанса, считайте свои записи). В некоторых случаях непротиворечивость сеанса не может быть необходима для остальной части сеанса, но только для некоторых, немногих операций чтения. Таким образом, master_on_write может привести к более загрузке чтения на ведущем устройстве чем необходимый. В тех случаях лучше запросить более высокое чем уровень обслуживания значения по умолчанию только для тех чтений, которые фактически нуждаются в этом. Как только чтения делаются, приложение может возвратиться к уровню обслуживания значения по умолчанию. Переключение между уровнями обслуживания является только возможным использованием mysqlnd_ms_set_qos.

Соображения производительности

Кластер репликации MySQL не может сказать клиентам, какие ведомые устройства способны к поставке который уровень обслуживания. Таким образом, в некоторых случаях, клиенты должны запросить ведомые устройства, чтобы проверить их состояние. PECL mysqlnd_ms прозрачно выполняет необходимый SQL в фоновом режиме. Однако, это - дорогая и медленная работа. SQL-операторы выполняются, если возможная непротиворечивость объединяется с возрастом (ведомая задержка) предел и если непротиворечивость сеанса объединяется с глобальным ID транзакции.

Если возможная непротиворечивость объединяется с максимальным возрастом (ведомая задержка), плагин выбирает кандидатов на выполнение оператора и выравнивание нагрузки для каждого оператора следующим образом. Если оператор является записью, все ведущие устройства рассматривают как кандидатов. Ведомые устройства не проверяются и не рассматриваются как кандидатов. Если оператор является чтением, плагин прозрачно выполняется SHOW SLAVE STATUS на каждом ведомом соединении. Это циклично выполнится по всем соединениям, отправить оператор и затем начать проверять на результаты. Обычно, это немного быстрее чем цикл по всем соединениям, в которых для каждого соединения запрос, передаются, и плагин ожидает своих результатов. Ведомое устройство считают кандидатом если SHOW SLAVE STATUS отчеты Slave_IO_Running=Yes, Slave_SQL_Running=Yes и Seconds_Behind_Master меньше или равно чем позволенный максимальный возраст. В случае ошибки SQL плагин испускает предупреждение, но не устанавливает ошибку на соединении. Ошибка не устанавливается позволить использовать плагин в качестве понижения.

Если непротиворечивость сеанса объединяется с глобальным ID транзакции, плагин выполняет набор SQL-оператора с fetch_last_gtid запись global_transaction_id_injection раздел от конфигурационного файла плагинов. Более подробная информация идентична описанным выше.

В версии 1.2.0 никакая дополнительная оптимизация не делается для того, чтобы выполнить фоновые запросы. Будущие версии могут содержать оптимизацию, в зависимости от пользовательского требования.

Если никакие параметры и опции не устанавливаются, никакой SQL не необходим. В этом случае, плагин считают все узлы типа показанными ниже.

Регулировка

Качество фильтра службы может быть объединено с Глобальными ID транзакции, чтобы отрегулировать клиенты. Регулировка действительно уменьшает загрузку записи на ведущем устройстве, замедляя клиенты. Если непротиворечивость сеанса требуют, и глобальные транзакции idenentifier используются, чтобы проверить состояние ведомого устройства, проверка может быть сделана двумя способами. По умолчанию ведомое устройство проверяется и сразу пропускается, если оно не соответствует критерии для непротиворечивости сеанса. Альтернативно, плагин может ожидать ведомого устройства, чтобы поймать до ведущего устройства, пока непротиворечивость сеанса не возможна. Чтобы включить регулировке, необходимо установить wait_for_gtid_timeout параметр конфигурации.

Copyright 1997-2012 PHP Documentation Group.

Идея и клиентская эмуляция

PECL/mysqlnd_ms может сделать сторону клиента прозрачная глобальная инжекция ID транзакции. В его наиболее канонической форме глобальный идентификатор транзакции является счетчиком, который постепенно увеличивается для каждой транзакции, выполняемой на ведущем устройстве. Счетчик сохранен в таблице на ведущем устройстве. Ведомые устройства тиражируют встречную таблицу.

В случае основного отказа администратор базы данных может легко идентифицировать новое ведомое устройство для promiting это как новое ведущее устройство. У нового ведомого устройства есть самый высокий идентификатор транзакции.

Разработчики приложений могут попросить у плагина глобальный идентификатор транзакции (GTID) для их последней успешной операции записи. Плагин возвратит идентификатор, который обращается к транзакции, не более старой чем тот из клиентов последняя операция записи. Затем, GTID можно передать в качестве параметра к качеству службы (QoS) фильтр как опция для непротиворечивости сеанса. Непротиворечивость сеанса гарантирует, читает Ваши записи. Фильтр гарантирует, что все чтения или направляются к ведущему устройству или ведомому устройству, которое тиражировало запись, на которую ссылается GTID.

Когда инжекция делается

Плагин прозрачно поддерживает таблицу GTID на ведущем устройстве. В режиме автоматической фиксации плагин вводит UPDATE оператор прежде, чем выполнить пользовательский оператор для каждого основного использования. В режиме ручной транзакции инжекция делается перед вызовами приложения commit() заключать сделку. Параметр конфигурации report_error из раздела GTID в плагинах конфигурационный файл используется, чтобы управлять, должна ли отказавшая инжекция прервать текущую работу или быть проигнорирована тихо (значение по умолчанию).

Пожалуйста, отметьте, требования версии PHP для контроля границы транзакции и их пределов.

Ограничения

У клиентской глобальной инжекции ID транзакции есть недостатки. Потенциальные проблемы не являются определенными для PECL/mysqlnd_ms, но скорее общего характера.

Используя серверный глобальный идентификатор транзакции

Запускаясь с PECL/mysqlnd_ms, с 1.3.0 альфами MySQL, 5.6.5-m8 или более новая встроенная глобальная функция идентификатора транзакции поддерживается. Использование функции сервера снимает все вышеупомянутые перечисленные ограничения. Пожалуйста, см. MySQL Reference Manual для ограничений и предварительные условия для того, чтобы использовать сервер встроенные глобальные идентификаторы транзакции.

Использовать ли клиентскую эмуляцию или сервер, встроенная функциональность является вопросом, не непосредственно связанным с плагином, таким образом это не обсуждается подробно. Нет никаких планов удалить клиентскую эмуляцию, и можно продолжать использовать ее, если серверным решением не является никакая опция. Это может иметь место в неоднородных средах со старым сервером MySQL или, если какое-либо из серверных ограничений решения не является приемлемым.

С точки зрения приложений есть едва различие в использовании того или другого подхода. Следующие свойства отличаются.

Copyright 1997-2012 PHP Documentation Group.

Поддержка кластеров репликации MySQL (асинхронная основная копия) является основным фокусом PECL/mysqlnd_ms. Ведомые устройства кластера репликации MySQL могут или, возможно, не отражают последние обновления от ведущего устройства. Ведомые устройства являются асинхронными и могут отстать от ведущего устройства. Чтение от ведомого устройства возможно непротиворечивый с точки зрения всего кластера.

Тот же самый уровень непротиворечивости предлагается локальным кэшем, использующим время-к-живому (TTL) стратегия аннулирования. Текущие данные или устаревшие данные могут быть поданы. В конечном счете данные, разыскиваемые в кэше, не доступны, и к источнику кэша нужно получить доступ.

Учитывая, что оба, которых ведомое устройство MySQL Replication (асинхронное вторичное устройство) и локальный управляемый TTL кэш поставляет тому же самому уровню обслуживания, возможно прозрачно заменить удаленный доступ к БД локальным доступом кэша, чтобы получить лучшую возможность.

С PECL/mysqlnd_ms, с 1.3.0 бетами, плагин способен к прозрачному управлению PECL/mysqlnd_ms, с 1.1.0 альфами или более новым, чтобы кэшировать запрос только для чтения если явно позволено, устанавливая соответствующее качество службы через mysqlnd_ms_set_qos. Пожалуйста, см. быстрый запуск для примера кода. Оба плагина должны быть установлены, PECL/mysqlnd_ms должен быть скомпилирован, чтобы поддерживать функцию кэша, и PHP 5.4.0 или более новый должен использоваться.

Приложения имеют полный контроль над использованием кэша и могут запросить новые данные в любое время в случае необходимости. Использование боли Thec может быть включено и отключенное время во время выполнения сценария. Кэш будет использоваться если mysqlnd_ms_set_qos устанавливает качество службы к возможной непротиворечивости и включает использованию кэша. Использование кэша отключается, запрашивая более высокие уровни непротиворечивости, например, непротиворечивость сеанса (считайте свои записи). Как только качество службы было ослаблено к возможной непротиворечивости, кэш может использоваться снова.

Если кэширование включается для оператора только для чтения, PECL/mysqlnd_ms может ввести подсказки SQL, чтобы управлять кэшированием PECL/mysqlnd_qc. Это может изменить SQL-оператор, который это получило из приложения. Последующие процессоры SQL, как предполагается, игнорируют подсказки SQL. Подсказка SQL является комментарием SQL. Комментарии не должны быть проигнорированы, например, сервером базы данных.

TTL записи кэша вычисляется на на основание оператора. Набор приложений максимальный возраст для данных они хотят получить использование mysqlnd_ms_set_qos. Возраст устанавливает приблизительный верхний предел того, сколько секунд возвращенные данные могут отстать от ведущего устройства.

Следующая логика используется, чтобы вычислить фактический TTL, если кэширование включается. Логика принимает предполагаемую ведомую задержку во внимание для того, чтобы выбрать TTL. Если, например, есть два ведомых устройства, изолирующие 5 и 10 секунд позади, и максимальный позволенный возраст составляет 60 секунд, TTL устанавливается в 50 секунд. Пожалуйста, отметьте, установка возраста является не больше, чем предполагаемым предположением.

Алгоритм может казаться дорогим. SHOW SLAVE STATUS очень быстрая работа. Учитывая достаточное число запросов и удачных обращений в кэш в секунду стоимость проверки ведомой задержки может легко outweight затраты решения кэша.

Предложения на лучшем алгоритме всегда приветствуются.

Copyright 1997-2012 PHP Documentation Group.

Любое приложение, используя любой вид кластера MySQL сталкивается с теми же самыми задачами:

Плагин оптимизируется для того, чтобы выполнить эти задачи в контексте классического асинхронного кластера репликации MySQL, состоящего из единственного ведущего устройства и многих ведомых устройств (основная копия). При использовании классической, асинхронной репликации MySQL со всеми вышеупомянутыми перечисленными задачами нужно освоить в стороне клиента.

У других типов кластера MySQL могут быть более низкие требования к стороне приложения. Например, если все узлы в кластере могут ответить на чтение и записать запросы, никакое разделение чтения-записи не должно быть сделано (мультиведущее устройство, обновление - все). Если все узлы в кластере синхронны, они автоматически обеспечивают максимально возможное качество службы, которая делает выбор узла легче. В этом случае плагин может вручить приложение после некоторого реконфигурирования, чтобы отключить определенные опции, такие как встроенное разделение чтения-записи.

Основная копия (MySQL Replication)

Это - основной вариант использования плагина. Следуйте за подсказками, данными в описаниях каждой функции.

mysqlnd_ms.enable=1mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini

{  "myapp": {    "master": {      "master_1": {        "host": "localhost",        "socket": "\/tmp\/mysql57.sock"      }    },    "slave": {      "slave_0": {        "host": "127.0.0.1",        "port": 3308      },      "slave_1": {        "host": "192.168.2.28",        "port": 3306      }    },    "filters": {      "random": {        "sticky": "1"      }    }  }}

Основная копия со много основными устройствами (MMM - MySQL Multi Master)

MySQL Replication позволяет Вам создавать топологию кластера с многократными ведущими устройствами (основные устройства). Конфликты записи записи не обрабатываются системой репликации. Это не обновление, где угодно устанавливают. Таким образом данные должны быть разделены вручную, и клиенты должны перенаправленный в соответствии с правилами разделения. Рекомендуемая установка равна установке sharding ниже.

Руководство sharding, возможно объединенный с основной копией и многократными основными устройствами

Используйте подсказки SQL и групповой фильтр узла для кластеров, которые используют разделение данных, но перенаправление запроса отпуска клиенту. Конфигурация в качестве примера показывает много основную установку с двумя черепками.

mysqlnd_ms.enable=1mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.inimysqlnd_ms.multi_master=1

{  "myapp": {    "master": {      "master_1": {        "host": "localhost",        "socket": "\/tmp\/mysql57.sock"      }      "master_2": {        "host": "192.168.2.27",        "socket": "3306"      }    },    "slave": {      "slave_1": {        "host": "127.0.0.1",        "port": 3308      },      "slave_2": {        "host": "192.168.2.28",        "port": 3306      }    },    "filters": {      "node_groups": {        "Partition_A" : {          "master": ["master_1"],          "slave": ["slave_1"]        },        "Partition_B" : {          "master": ["master_2"],          "slave": ["slave_2"]        }      },      "roundrobin": []    }  }}

Плагин может также использоваться со свободным набором несвязанных черепков. Для такого кластера сконфигурируйте ведущие устройства только и отключите разделение записи чтения. Узлы такого кластера вызывают ведущими устройствами в сменной конфигурации, поскольку они принимают и чтения и записи для их раздела.

Используя синхронное обновление всюду кластеры, такие как MySQL Cluster

MySQL Cluster является синхронным решением для кластера. Все узлы кластера принимают запросы записи и чтение. В контексте плагина все узлы нужно рассмотреть как ведущие устройства.

Используйте выравнивание нагрузки и сбой по функциям только.

Отключение встроенного разделения чтения-записи.

Сконфигурируйте ведущие устройства только.

mysqlnd_ms.enable=1mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.inimysqlnd_ms.multi_master=1mysqlnd_ms.disable_rw_split=1

  "myapp": {    "master": {      "master_1": {        "host": "localhost",        "socket": "\/tmp\/mysql57.sock"      },      "master_2": {        "host": "192.168.2.28",        "port": 3306      }    },    "slave": {    },    "filters": {      "roundrobin": {      }    },    "failover": {      "strategy": "loop_before_master",      "remember_failed": true    }  }}

Выполняя обновление всюду кластер, у которого нет никакого встроенного разделения, чтобы избежать горячих точек и высокого уровня аварийности, рассматривает использование группового фильтра узла, чтобы сохранить обновления о таблице, к которой часто получают доступ, на одном из узлов. Это может помочь уменьшить уровень аварийности и таким образом улучшить производительность.