Архив за месяц: Апрель 2015

Перенос Exchange 2010 CAS+Hub на другой сервер при наличии Edge

Иногда возникает необходимость переноса Exchange-сервера на другое железо. В теории, в этом нет ничего сложного:

— Останавливаем существующий сервер;
— Устанавливаем ОС на новый, выдаем ему то же имя;
— Включаем новый сервер в домен;
— Устанавливаем весь необходимый софт (Microsoft Filter Pack, .NET 3.5) и необходимые роли/фичи сервера (можно подсмотреть здесь);
— Запускаем setup /m:RecoverServer и отдыхаем.

Но если ваша конфигурация Exchange содержит Edge-сервера, то на этапе проверки перед установкой вы получите следующую ошибку:

[ERROR] The internal transport certificate for the local server was damaged or missing in Active Directory. The problem has been fixed. However, if you have existing Edge Subscriptions, you must subscribe all Edge Transport servers again by using the New-EdgeSubscription cmdlet in the Shell.

И ведь, вроде как, в ошибке написано, что «problem has been fixed». Но как бы не так. Перезапуск установки с тем же ключом выдает такую же ошибку.

Для решение этой проблемы, необходимо сходить на контроллер домена, запустить там adsiedit и зайти в Configuration partition –> Services -> Microsoft Exchange –> _ВАША_ОРГАНИЗАЦИЯ –> Administrative Groups –> Exchange Administrative Group (FYDIBOHF23SPDLT) –> Servers –> _ИМЯ_ВАШЕГО_СЕРВЕРА_. По имени сервера необходимо кликнуть правой кнопкой и зайти в Properties. В списке свойств необходимо найти «msExchEdgeSyncCredential» и удалить все, что там есть.

Перезапускаем установку с помощью setup /m:recoverserver и не забываем перезагрузить сервер по окончании установки.

После перезагрузки, необходимо снова «связать» Hub Transport и Edge. Для этого необходимо запустить на Edge-сервере powershell и выполнить команду:

New-EdgeSubscription -FileName "c:\EdgeServerSubscription.xml"

Копируем файл EdgeServerSubscription.xml на наш hub transport, заходим в консоль управления Exchange->Organiztion Configuration->Hub Transport->Edge Subscriptions. Нажимаем New edge subscription, выбираем AD site, subscription file и нажимаем кнопку New.

Если серверов несколько — повторяем эту процедуру для каждого Edge и для каждого Hub.

Восстановление данных из горячего InnoDB-бэкапа без перезапуска сервера

Каждый человек, который делает бэкапы каких-либо приложений (при копировании чего-либо отличного от обычных файлов) должен знать и понимать, что бэкап — это только половина дела по обеспечению надежности функционирования и защищенности данных сервиса от потери. Вторая, не менее важная, половина — это умение этот бэкап восстановить. По-хорошему, бэкапы надо регулярно восстанавливать в «тестовых» условиях, так сказать, проводить учения :) Чтобы при возникновении необходимости восстановления, не было вопросов типа «а что с этим делать?».

В случае с MyISAM-таблицами все обстоит совсем просто. Если сделать «flush tables with read lock», то их можно даже скопировать на файловом уровне. Хоть официально это и не поддерживается, но чаще всего работает «на ура». С InnoDB-таблицами все намного сложнее…

Для восстановления нам понадобится mysql-сервер той же версии, как и на «боевом» сервере. Если бэкапы делались при помощи снэпшотов и они еще не удалены с сервера, то на «боевом» сервере их восстановить будет даже проще — локально скопировать несколько файлов куда проще, чем доставать из архива и копировать по сети. Итак, для восстановления базы из горячего бэкапа в случае InnoDB-таблиц нам понадобится:

1) Копируем файл конфигурации с рабочего варианта (/etc/my.cnf в /etc/my2.cnf) и заменяем в нем: порт, который слушает mysql (3306) на любой другой (3307, например); сокет, который слушает mysql (/tmp/mysql.sock на /tmp/mysql2.sock); pid-файл (mysql.pid на mysql2.pid); директорию с файлами БД (/var/db/mysql на /var/db/mysql2).

2) Копируем в /var/db/mysql2 файлы из корня бэкапа (т.е. ib_logfile0, ib_logfile1 и др). Копируем из бэкапа директории performance_schema и mysql, а также директорию с базой данных, которую мы хотим восстановить.

3) Проверяем права на директорию /var/db/mysql2. Они должны быть такими же, как и на директорию /var/db/mysql.

4) Запускаем вторую копию mysql командой:

mysqld_safe --defaults-file=/etc/my2.cnf &

5) Запускаем mysqldump с необходимыми ключами (набор которых зависит от размера БД, количества памяти на сервере и т.д.). Если вы не знаете, какие ключи вам нужны, можете запускать его совсем без ключей. Главное — указать сокет:

mysqldump -S /tmp/mysql2.sock database_to_dump > /path/to/save/dump

6) Если дамп прошел успешно — гасим вторую копию mysql командой:

mysqladmin -S /tmp/mysql2.sock shutdown

После всего этого у нас будет дамп базы данных на руках. А с ним уже можно делать все, что душе угодно :)

Спасение сервера от медленных запросов mysql

Медленные запросы к mysql могут возникать по разным причинам: недостаточная производительность процессора, неоптимизированные запросы, криво настроенный сервер, большое количество «случайных» операций чтения и др. Иногда, во имя спасения всего сервера, легче «заставить» сервер отказаться от выполнения долгах запросов. К сожалению, mysql-сервер не умеет ограничивать максимальное время выполнения запроса. Поэтому приходится искать альтернативные пути. А именно, убивать запросы, которые выполняются дольше, чем мы хотим. Конечно, в таком случае работа веб-приложения завершится с ошибкой и, скорее всего, пользователь увидит HTTP 500, но бывают такие случаи, когда лучше отдать одному пользователю HTTP 500, чем всем остальным показать таймаут.

Итак, встречайте: очередной тул от percona — pt-kill! На FreeBSD ставится вот отсюда: /usr/ports/databases/percona-toolkit . Pt-kill — это такая маленькая, но полезная утилитка, которая умеет опрашивать mysql-сервер раз в n секунд и убивать медленные запросы. В общем-то, на этом ее функционал не ограничивается, но в данный момент нас интересует именно эта часть.

Для начала, можно проверить работу pt-kill в «тестовом» режиме. Вместо завершения соединений, он будет просто показывать те запросы, которые подходят под его условия. Для этого надо запустить его примерно такой командой:

pt-kill --busy-time 60 --print

В этом примере он должен выводить в консоль запросы, которые перешагнули порог в 60 секунд. Таймаут, необходимый вам, лучше подбирать самостоятельно исходя из характера нагрузки на сервер. В общем случае для сервера, на котором крутится не только mysql, но и apache, я бы рекомендовал выставлять его таким, чтобы количество процессов веб-сервера не начало расти из-за того, что mysql не успевает отдавать данные.

И, если вы все же уверены в том, что все эти запросы необходимо убивать, можете запустить его следующим образом:

pt-kill --busy-time 60 --print --kill

В таком режиме он будет выводить на экран и убивать по одному медленному запросу за один раз (самому «старому»). Если надо убивать их все сразу (допустим, одновременно их появилось 10 штук), надо указать ключ —victims all. И, наконец, если вы хотите, чтобы он работал в фоне, смело убирайте —print и добавляйте —daemonize.

pt-kill --busy-time 60 --kill -- victims all --daemonize

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