Архив категорий Linux

Автор:human

Ext4 or XFS risize online without downtime debian/ubuntu system

Для того, чтобы сделать resize ext4 online, необходимо проделать несколько операций

Получаем данные. На основе их делаем рескан

Удаляем текущие разделы
Создаем новый раздел, делаем его bootable — не забываем. Сохраняемся.
Делаем partprobe

Делаем resize для ext4

Делаем resize для xfs по точке монтированя

Готово

Автор:human

мини-лайфхаки в Bash

1. Чтобы быстро скопировать/переименовать файл с длинным именем, можно набрать:

и обратно:

2. Бесполезная, но прикольная форк-бомба (правда, не сработает, если у Вас задан ulimit для количества процессов):

3. Эмулятор сетевого принтера на локальном компьютере:

4. Простейшее нагрузочное тестирование веб-сайта:

5. Удобочитаемый вывод команды mount:

6. SSH туннель с локального порта 7777 на удаленный порт 8888 на сервере myserver.com:

7. Вывести случайное число от 0 до 32767:

echo $RANDOM

8. Выполнить в консоли команды из текстового файла:

9. Создать случайный пароль:

10. Защита от одновременного запуска нескольких копий скрипта:

11. Собрать все строки в одну строку с разделителем,на примере ;

еще один вариант

Обрезать строку после точки , например при catr

Автор:human

Mysql репликация и переключение на новый мастер

Настройка репликации MySQL, аварийное переключение slave->master

  • Увеличение производительности СУБД путем подключения к ней серверов для адаптации к возрастающей нагрузке. Производительность растет за счет выделения одного сервера преимущественно для модификации данных (master) и остальных для чтения данных (slaves). Данное решение особенно эффективно для веб-приложений: у данной категории приложений большая часть запросов к СУБД — запросы на чтение.
  • Онлайн бэкап — данные передаются в режиме онлайн на резервные/slave-сервера. При отказе основного сервера на одном из резервных/slave серверов имеется «свежая» копия данных.
  • Организация эффективного резервного копирования: бэкап делается с резервного сервера без прерывания /замедления работы основного сервера СУБД. При необходимости для осуществления целостного бинарного бэкапа СУБД (в особенности InnoDB) можно остановить на необходимое время резервный сервер, выполнить бэкап и запустить резервный сервер снова.
  • Обеспечение высокой доступности: при выходе из строя одного из серверов СУБД система продолжает обрабатывать запросы.

Примечание: Подробнее о примерах использования репликации MySQL читайте в официальной документации.

 

Надежность репликации

Для обеспечения максимальной надежности репликации рекомендуется установить параметры MySQL следующим образом:
innodb_flush_log_at_trx_commit = 1

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

Для повышения производительности можно использовать такие параметры (чревато потерей данных нескольких транзакций в момент аварии на базе данных):

Динамический hostname

Если у настраиваемого сервера динамический IP-адрес/hostname, рекомендуется явно задать параметры:

Привилегии

Для работы репликации учетные записи основного и резервных master/slave-серверов должны иметь, кроме стандартных, также привилегии:

Учетные записи

Временные зоны

Если сервера СУБД кластера расположены в разных дата-центрах, необходимо настроить на них единую временную зону.

 

Администрирование репликации

Репликация после настройки работает надежно и требует минимального администрирования. Тем не менее, рекомендуется периодически проверять ее состояние утилитами мониторинга операционной системы (nagios, zabbix, monit, linux-ha).

В маловероятном случае возникновения ошибки на slave-сервере рекомендуется его переинициализировать — заново залить на него данные с основного сервера. Для этого нужно его Прекратить использовать, а затем Начать использовать в разделе Репликация (Настройки > Веб-кластер > Репликация).

Резервное копирование

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

 

Переключение slave->master в случае отказа master

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

Общая схема этой процедуры такова:

  1. Закрываем доступ клиентов к веб-приложениюЕсли используется двухуровневая конфигурация (фронтэнд nginx — бэкэнд apache и т.п.), рекомендуется на фронтэнде отключить доступ к бэкэнду (веб-приложению) и отдавать при обращении клиентов к кластеру информационную страницу о регламентных работах.
  2. Останавливаем на всех slave-серверах поток получения обновлений бинарного лога с основного (master) сервера:

    Ждем, пока от потока выполнения команд slave (SQL_THREAD) не появится сообщение "Has read all relay log; waiting for the slave I/O thread to update it", говорящее о том, что slave-сервер выполнил все команды из relay-лога в своей базе. Сразу останавливать slave командой STOP SLAVE не рекомендуется, т.к. не все SQL-команды могут быть выполнены из relay-лога (по причине отставания и т.п.), а при переключении slave на новый мастер, relay-лог будет очищен и, возможно, потеряется часть «непроигранных» данных.
  3. Подготовка нового master-сервераУбеждаемся, что на slave-сервере, который мы хотим сделать master-сервером, бинарный лог ведется и не логируются запросы из master:

    Полностью останавливаем slave — потоки чтения бинарного лога и выполнения SQL-команд:

    Команда RESET MASTER необходима для очистки бинарного лога нового master, иначе, если в бинарном логе будут записи (устаревшие и т.п.), они проиграются на подключаемых к нему slave-серверах. Такое возможно, если сервер был master с включенным бинарным логом, потом стал slave и перестал использовать бинарный лог, потом снова переводится в режим master.
    Итак, новый master подготовлен, у него очищен бинарный лог, и он готов обрабатывать запросы.
  4. Переключение slave-серверов на новый master-серверНа всех slave-серверах выполняем:

    В момент выполнения на slave

    очищается

    slave-сервера, а позиция c которой читается бинарный лог master-сервера устанавливается, если не задано иное, в значение по умолчанию: первый файл бинарного лога, 4 позиция (т.е. в самое начало бинарного лога master-сервера).

  5. Переключаем веб-приложение на новый master-серверНеобходимо настроить кластер на использование нового master-сервера.
  6. Открываем доступ клиентов к веб-приложениюЕсли используется двухуровневая конфигурация (фронтэнд nginx — бэкэнд nginx+php-fpm и т.п.), на фронтэнде убираем информационную страницу о регламентных работах и переключаем запросы на бэкэнд (веб-приложение).В итоге кластер использует новый master-сервер.

Еще один способ переключения slaves на нового master

На мастере

На слейве 1

Optional: CHANGE MASTER TO MASTER_HOST=»;

На слейве 2

Автор:human

Rsync make from source 3.1.1 or 3.1.2

Rsync make from source 3.1.1 or 3.1.2

Если у вас старая версия debian, а вам необходима версия rsync выше чем 3.0.9, то вам сюда

Профит

Яндекс.Метрика