Способ избежать времени простоя сервера при создании Ведущего устройства - Ведомые отношения?
Поскольку другие сказали, что семафорами является IPC (структуры межпроцессных взаимодействий). Семафоры как весь IPC используются, чтобы позволить различным процессам общаться друг с другом.
Они - в основном счетчики, которые созданы, получены доступ и уничтожили использующие специальные системные вызовы, такие как sempost (3), semwait (3), semget (2) и semop (2). См. sem_overview (7) в системе Linux для краткого описания.
Определение связывается, здесь довольно примитивно. "Свяжитесь" для средств семафоров читать, увеличив или постепенно уменьшив счетчик через упомянутые выше вызовы системы/библиотеки.
Специальная вещь о семафорах кроме того, что они, состоит в том, что только один процесс за один раз может выполнить операцию на них, и семафорные операции гарантируются атомарные, то есть Вы не можете войти в состояние состязания по семафору, поскольку ядро не выгрузит процесс, который выполняет семафорную операцию.
Другая специальная вещь состоит в том, что они создаются в общей памяти, которая позволяет нескольким процессам получать доступ к ним.
То, как они проявляют/создают, - то, что программы создают их использующий semget (2). Например, апач создает семафоры, когда он работает.
ipcs-l скажет Вам о ресурсах IPC системы.
Можно управлять некоторым системным семафором и связанными с IPC пределами с sysctls. Попробовать sysctl kernel.sem просмотреть связанные с семафором настройки через sysctl. Если Вы хотите сохраниться, любой sysctl изменяет Вас, попытка поместила их в /etc/sysctl.conf.
Если вы используете 100% InnoDB, то вам повезло. Вы можете использовать XtraBackup , чтобы сделать полную резервную копию вашей главной базы данных без простоев или блокировок таблиц. Это будет последовательная резервная копия в стиле моментальных снимков, такая же, как при сортировке, которую вы получаете, когда выполняете параметры FLUSH TABLES WITH READ LOCK или - master-data .
Инструмент XtraBackup также помещает дополнительный файл в каталог резервного копирования, который содержит информацию MASTER_LOG_POS и MASTER_LOG_FILE, необходимую для начала репликации на ведомом устройстве.
После того, как вы закончите резервное копирование, вам нужно будет запустить XtraBackup - подготовьте опцию в резервной копии, загрузите ее в ведомое устройство, запустите резервный процесс MySQL ведомого устройства и сообщите ему новые необходимые значения MASTER_LOG_POS и MASTER_LOG_FILE.
Вам понадобится skip-slave-start в вашем my.cnf перед запуском ведомого.
Также имейте в виду, что схема mysql по умолчанию является MyISAM (и если память обслуживается правильно, это может быть только MyISAM), поэтому вам все равно придется быть осторожным, чтобы не вносить никаких изменений в какие-либо из этих таблиц во время резервного копирования. Пока вы придерживаетесь этого правила, информация о главном устройстве будет по-прежнему верной.
Часто рекомендуется игнорировать схему mysql в вашем my.cnf на ведомом устройстве. и создавать пользователей только с привилегиями SELECT. Несогласованные и несинхронизированные ведомые устройства трудно обнаружить, и с ними сложно справиться даже при использовании инструментов, которые Percona (и Maatkit до них) предоставляют для этого.
Редактировать:
Хотя вы сказали, что используете InnoDB, для полноты есть другой способ, если вы используете таблицы MyISAM. Если у вас есть диспетчер томов с моментальным снимком (например, ZFS или LVM ), вы можете запустить FLUSH TABLES WITH READ LOCK с последующим SHOW СОСТОЯНИЕ МАСТЕРА , создайте моментальный снимок и запустите РАЗБЛОКИРОВАТЬ ТАБЛИЦЫ . Время простоя должно быть минимальным. Для сравнения: вчера вечером задание cron, выполнявшее это для резервного копирования одной из наших баз данных, заняло 6 секунд для создания моментального снимка, который является битом, в котором база данных «не работает», и 27 минут для копирования файлов из моментального снимка на сервер резервного копирования.
FLUSH TABLES WITH READ LOCK , за которым следует SHOW MASTER STATUS , создать моментальный снимок и запустить UNLOCK TABLES . Время простоя должно быть минимальным. Для сравнения: вчера вечером задание cron, выполнявшее это для резервного копирования одной из наших баз данных, заняло 6 секунд для создания моментального снимка, который является битом, в котором база данных «не работает», и 27 минут для копирования файлов из моментального снимка на сервер резервного копирования. вы можете запустить FLUSH TABLES WITH READ LOCK , за которым следует SHOW MASTER STATUS , создать моментальный снимок и запустить UNLOCK TABLES . Время простоя должно быть минимальным. Для сравнения: вчера вечером задание cron, выполнявшее это для резервного копирования одной из наших баз данных, заняло 6 секунд для создания моментального снимка, который является битом, в котором база данных «не работает», и 27 минут для копирования файлов из моментального снимка на сервер резервного копирования. 172.16.XX маска подсети по умолчанию 255.255.0.0, вы перенастроили ее на 255.255.255.0. Таким образом, хосты 172.16.0.x и 172.16.1.x находятся в разных подсетях. таким образом, он попытается МАРШРУТИЗИРОВАТЬ его через шлюз по умолчанию.
Изменение маски подсети на 255.255.0.0 решит проблему.
Не могли бы вы предоставить диаграмму. Если вы не можете нарисовать сеть, это не может быть исправлено (старая пословица сетевых инженеров ... мною!).
Ура,
сам по себе из-за конфликта блокировок - он устанавливает блокировки чтения для всех таблиц (аналогично тому, что делает команда FLUSH TABLES WITH READ LOCK) на все время создания дампа. Таким образом, запросы на запись ни в одну из таблиц не вернутся, если дамп не будет завершен. Кроме того, запросы на запись, вероятно, также будут блокировать любые последующие запросы чтения, если вы не указали low_priority_updates в своей конфигурации MySQL или не передали дампу SET GLOBAL LOW_PRIORITY_UPDATES = 1.