Введение
Эта статья в первую очередь рассчитана на новичков в администрировании, для тех, кто хочет научиться самостоятельно производить импорт и экспорт баз данных. Зачем вам может это понадобиться? Допустим, вы хотите самостоятельно сделать бэкап, чтобы в дальнейшем при необходимости восстановить определенную версию базы данных. Или вам нужно сделать перенос сайта на другой сервер либо в другую среду разработки. В общем, причин может быть множество, поэтому понимание того, как сначала сделать, а потом импортировать резервную копию, лишним не будет.
Для того, чтобы выполнить все дальнейшие действия, у вас должны быть:
а) доступ к серверу на базе Linux, на котором работает MySQL/MariaDB;
б) название базы данных и данные доступа к ней.
Процедура восстановления после сбоя Failure Recovery Procedure
Если нужно перенести файл из-за сбоя оборудования, необходимо выполнить приведенные ниже действия для его перемещения на новое место. If a file must be moved because of a hardware failure, follow these steps to relocate the file to a new location. Данная процедура применима ко всем системным базам данных, кроме master и Resource. This procedure applies to all system databases except the master and Resource databases.
Если базу данных запустить нельзя, она находится в подозрительном режиме или в невосстановленном состоянии, то файл может быть перемещен только членом предопределенной роли sysadmin. If the database cannot be started, that is it is in suspect mode or in an unrecovered state, only members of the sysadmin fixed role can move the file.
Остановите работу экземпляра SQL Server SQL Server , если он запущен. Stop the instance of SQL Server SQL Server if it is started.
Запустите экземпляр SQL Server SQL Server в режиме восстановления «только master», запустив из командной строки одну из следующих команд. Start the instance of SQL Server SQL Server in master-only recovery mode by entering one of the following commands at the command prompt. В задаваемых для них параметрах учитывается регистр символов. The parameters specified in these commands are case sensitive. Команды завершаются ошибкой, если параметры заданы не так, как показано. The commands fail when the parameters are not specified as shown.
В случае с экземпляром по умолчанию (MSSQLSERVER) запустите следующую команду: For the default (MSSQLSERVER) instance, run the following command:
В случае с именованным экземпляром запустите следующую команду: For a named instance, run the following command:
Для каждого перемещаемого файла используйте команды sqlcmd или SQL Server Management Studio SQL Server Management Studio для выполнения следующей инструкции. For each file to be moved, use sqlcmd commands or SQL Server Management Studio SQL Server Management Studio to run the following statement.
Дополнительные сведения об использовании программы sqlcmd см. в статье Использование программы sqlcmd. For more information about using the sqlcmd utility, see Use the sqlcmd Utility.
Завершите работу программы sqlcmd или SQL Server Management Studio SQL Server Management Studio . Exit the sqlcmd utility or SQL Server Management Studio SQL Server Management Studio .
Остановите экземпляр SQL Server SQL Server . Stop the instance of SQL Server SQL Server . Например, выполните команду NET STOP MSSQLSERVER . For example, run NET STOP MSSQLSERVER .
Переместите файл или файлы в новое расположение. Move the file or files to the new location.
Повторно запустите экземпляр SQL Server SQL Server . Restart the instance of SQL Server SQL Server . Например, выполните команду NET START MSSQLSERVER . For example, run NET START MSSQLSERVER .
Проверьте изменения в файле с помощью следующего запроса. Verify the file change by running the following query.
Создание новых событий MySQL
Создание события производится аналогично созданию других объектов базы данных: таких как хранимые процедуры и триггеры.
Событие представляет собой проименованный объект, который содержит состояние SQL.
Хранимая процедура выполняется только при прямом вызове; триггер выполняется, когда происходит событие, связанное с таблицей: например добавление, обновление, или удаление. В то время как само событие может выполняться один или несколько раз с регулярным интервалом.
Чтобы создать и запланировать новое событие, нужно использовать оператор CREATE EVENT следующим образом:
CREATE EVENT event_name ON SCHEDULE schedule DO event_body
Давайте рассмотрим этот оператор более подробно:
- Во-первых, после CREATE EVENT необходимо указать имя события. Оно должно быть уникальным в структуре базы данных;
- Во-вторых, после оператора ON SCHEDULE вы задаете график. Если событие является единичным, используется синтаксис: AT timestamp . Если событие периодическое, используется условие EVERY: EVERY interval STARTS timestamp ENDS timestamp ;
- В-третьих, вы размещаете оператор SQL после ключевого слова DO. Стоит отметить, что вы можете вызвать хранимую процедуру внутри тела события. В случае если у вас есть составные операторы SQL, вы можете заключить их в блок BEGIN END.
Давайте рассмотрим несколько примеров создания события, которые позволят лучше понять приведенный выше синтаксис.
Чтобы создать и запланировать новое одноразовое событие, которое добавляет сообщение в таблицу сообщений, нужно сделать следующее:
Во-первых, нужно с помощью оператора CREATE TABLE создать новую таблицу с именем messages:
CREATE TABLE IF NOT EXISTS messages (
id INT PRIMARY KEY AUTO_INCREMENT,
message VARCHAR(255) NOT NULL,
created_at DATETIME NOT NULL
);
Во-вторых, создаем событие с помощью оператора CREATE EVENT:
CREATE EVENT IF NOT EXISTS test_event_01
ON SCHEDULE AT CURRENT_TIMESTAMP
DO
INSERT INTO messages(message,created_at)
VALUES('Test MySQL Event 1',NOW());
В-третьих, проверяем таблицу messages. Вы увидите, что у нас есть одна запись. Это значит, что событие было выполнено во время его создания:
SELECT * FROM messages;
Для вывода всех событий базы данных, можно использовать следующий оператор:
SHOW EVENTS FROM classicmodels;
Мы видим, что нам не возвращается ни одна запись, потому что событие автоматически удаляется, когда истек его срок. В нашем случае это одноразовое событие, и его срок истек, когда его исполнение было завершено.
Чтобы изменить этот сценарий, вы можете использовать условие ON COMPLETION PRESERVE. Следующий оператор создает еще одно одиночное событие, которое выполняется спустя 1 минуту после его создания и не удаляется после выполнения:
CREATE EVENT test_event_02
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
ON COMPLETION PRESERVE
DO
INSERT INTO messages(message,created_at)
VALUES('Test MySQL Event 2',NOW());
Спустя 1 минуту проверяем таблицу сообщений, и видим, что в нее была добавлена еще одна запись:
SELECT * FROM messages;
Если мы снова запустим на исполнение оператор SHOW EVENTS, то увидим, что события все еще хранятся в структуре базы данных, потому что мы использовали условие ON COMPLETION PRESERVE:
SHOW EVENTS FROM classicmodels;
Следующий оператор создает повторяющееся событие, которое выполняется каждую минуту, и срок которого истекает спустя 1 час после времени его создания:
CREATE EVENT test_event_03
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP
ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
DO
INSERT INTO messages(message,created_at)
VALUES('Test MySQL recurring Event',NOW());
Обратите внимание, что мы использовали операторы STARTS и ENDS, чтобы задать для события срок действия. Вы можете протестировать это повторяющееся событие, подождав несколько минут, а затем вновь проверив таблицу сообщений:
SELECT * FROM messages;
Дефрагментация
Необходима для освобождения пространства, занимаемого файлом базы. Это связано с тем, что при удалении элементов, сама база не уменьшается.
Посмотреть, какое количество пространства удастся высвободить можно командой:
Get-MailboxDatabase -Status | ft Name, DatabaseSize, AvailableNewMailboxSpace
Пример ответа:
Name DatabaseSize AvailableNewMailboxSpace
—- ———— ————————
Base1 686.4 GB 286.4 MB
Base2 170 GB 69.42 GB
* где DatabaseSize — текущий размер базы; AvailableNewMailboxSpace — пространство, которое можно освободить при дефрагментации.
Саму оптимизацию можно выполнить двумя способами:
- Офлайн дефрагментация.
- Создание новой базы с последующим переносом в нее всех элементов; после, базу можно отключить и или удалить. Это более надежный вариант, так как не приведет к большому простою и позволит выполнить работу постепенно.
В текущем подразделе мы рассмотрим первый способ.
Офлайн дефрагментация приведет к отключению почтовой базы и, как следствие, приостановку работы почтовых ящиков, которые в нем содержатся.
Если используется база на основе группы DAG, сначала необходимо .
Операция дефрагментации выполняется из Exchange Management Shell с применением утилиты eseutil.
Сначала переходим в каталог хранения базы данных, например:
cd C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Base1
Выполняем команду для отмонтирования базы:
Dismount-Database Base1
* напомним, что это приведет к отключению базы и приостановки обслуживания.
Запускаем дефрагментацию:
eseutil /d Base1.edb /t \\share\base1_tmp.edb
* где опция d — имя файла базы; t — путь до временного файла на момент дефрагментации, если его не указать, временный файл будет создан в каталоге с основным файлом и, в таком случае, нужно убедиться, что на диске достаточно свободного места (110% от размер дефрагментируемого файла).
После завершения операции, снова подключаем базу:
Mount-Database Base1
Шаг 4 — Перезапуск MySQL
Теперь мы готовы запустить MySQL.
sudo systemctl start mysql sudo systemctl status mysql
Чтобы убедиться, что новая директория data действительно используется, зайдите в MySQL:
mysql -u root -p
И снова чтобы увидеть информацию о директории data введите:
select @@datadir;
+-------------------+ | @@datadir | +-------------------+ | /home/mial/mysql/ | +-------------------+ 1 row in set (0.00 sec)
Примечание: если значение не изменилось, то попробуйте перезапустить весь сервер, а не только службу MySQL.
Теперь, когда мы перезапустили MySQL и подтвердили, что используется новое расположение, воспользуйтесь возможностью убедиться, что ваша база данных полностью функционально. После того, как вы удостоверились в целостности всех существующих данных, вы можете удалить резервную копию директории data:
sudo rm -rf /var/lib/mysql.bak
Перезапустите MySQL последний раз, чтобы проверить, что всё работает как и ожидалось:
sudo systemctl restart mysql sudo systemctl status mysql
Важные заметки
- Убедитесь, что оба сервера MySQL установлены с одинаковым официальным дистрибутивом и версией. В противном случае вам нужно будет следовать инструкциям по обновлению с веб-сайта MySQL.
- Убедитесь, что на вашем старом сервере достаточно места для файла дампа и сжатого файла (2 x db_size => free).
- Убедитесь, что на вашем новом сервере достаточно места для хранения зашифрованного файла дампа, дешифрованного файла дампа и импортированной базы данных (3 x db_size => free).
- Если вы когда-нибудь задумывались о переносе datadir из одной базы данных в другую, пожалуйста, не делайте этого. если вы не хотите связываться с внутренней структурой базы данных, так как это, скорее всего, вызовет проблемы в будущем.
- Не забудьте настроить важные флаги, такие как innodb_log_file_size, в конфигурации вашего нового сервера. Если забыть обновить конфигурацию в соответствии со спецификациями нового сервера, это может привести к серьезным проблемам с производительностью.
Наслаждайтесь вашим новым сервером!
Перемещение базы данных master Moving the master Database
Чтобы переместить базу данных master, выполните следующие действия. To move the master database, follow these steps.
В меню Пуск выберите Все программы, укажите Microsoft SQL Server, затем Средства настройкии выберите пункт Диспетчер конфигурации SQL Server. From the Start menu, point to All Programs, point to Microsoft SQL Server, point to Configuration Tools, and then click SQL Server Configuration Manager.
Находясь в узле Службы SQL Server , щелкните правой кнопкой мыши экземпляр SQL Server SQL Server , например SQL Server (MSSQLSERVER) , и выберите пункт Свойства. In the SQL Server Services node, right-click the instance of SQL Server SQL Server (for example, SQL Server (MSSQLSERVER)) and choose Properties.
В диалоговом окне Свойства SQL Server ( имя_экземпляра ) перейдите на вкладку Параметры запуска . In the SQL Server (instance_name) Properties dialog box, click the Startup Parameters tab.
В поле Существующие параметры выберите параметр -d, чтобы переместить файл данных master. In the Existing parameters box, select the -d parameter to move the master data file. Нажмите Обновить для сохранения изменений. Click Update to save the change.
В поле Укажите параметр запуска задайте новый путь к базе данных master. In the Specify a startup parameter box, change the parameter to the new path of the master database.
В поле Существующие параметры выберите параметр -l, чтобы переместить файл журнала master. In the Existing parameters box, select the -l parameter to move the master log file. Нажмите Обновить для сохранения изменений. Click Update to save the change.
В поле Укажите параметр запуска задайте новый путь к базе данных master. In the Specify a startup parameter box, change the parameter to the new path of the master database.
Значение параметра для файла данных должно соответствовать параметру -d , а значение для файла журнала — параметру -l . The parameter value for the data file must follow the -d parameter and the value for the log file must follow the -l parameter. В следующем примере показаны значения параметров для указания местоположения файла базы данных master по умолчанию. The following example shows the parameter values for the default location of the master data file.
-dC:\Program Files\Microsoft SQL Server\MSSQL .MSSQLSERVER\MSSQL\DATA\master.mdf
-lC:\Program Files\Microsoft SQL Server\MSSQL .MSSQLSERVER\MSSQL\DATA\mastlog.ldf
Если планируется переместить файл данных базы данных master в расположение E:\SQLData , значения параметра будут изменены следующим образом. If the planned relocation for the master data file is E:\SQLData , the parameter values would be changed as follows:
Остановите работу экземпляра SQL Server SQL Server , щелкнув правой кнопкой мыши имя экземпляра и выбрав команду Остановить. Stop the instance of SQL Server SQL Server by right-clicking the instance name and choosing Stop.
Переместите файлы master.mdf и mastlog.ldf на новое место. Move the master.mdf and mastlog.ldf files to the new location.
Повторно запустите экземпляр SQL Server SQL Server . Restart the instance of SQL Server SQL Server .
Проверьте правильность изменений для базы данных master, выполнив следующий запрос. Verify the file change for the master database by running the following query.
На этом этапе среда SQL Server должна выполняться как обычно. At this point SQL Server should run normally. Однако корпорация Майкрософт рекомендует также изменить запись реестра, указанную в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\instance_ID\Setup , где instance_ID имеет вид MSSQL13.MSSQLSERVER . However Microsoft recommends also adjusting the registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\instance_ID\Setup , where instance_ID is like MSSQL13.MSSQLSERVER . В этом кусте измените значение SQLDataRoot на новый путь. In that hive, change the SQLDataRoot value to the new path. Невозможность обновления реестра может привести сбою исправления и обновления. Failure to update the registry can cause patching and upgrading to fail.
Перенос пользовательской базы данных¶
1. Договариваемся с творческой частью коллектива, что в определенное время все перестают работать с базой. А именно, прекращают что-то туда добавлять и/или изменять.
2. Останавливаем сервисы, которые работают с МБД в автоматическом режиме, например:
- DB Import — импорт новостных лент
- DDB — распределенная база данных
-
Sch_to_DB — репликация расписаний
иначе, есть вероятность потерять часть информации.
3. Запускаем Microsoft SQL Server Management Studio.
4. Самым первым делом всегда делаем бэкап базы!
5. Далее, смотрим, где лежат файлы нужной нам базы данных (в нашем примере это будет МБД под названием «RADIO-DB»). Для этого, нажимаем на ней ПКМ и открываем Properties (Свойства). Заходим в раздел Files (Файлы) и смотрим раздел Path (Путь):
6. Далее, нажимаем ПКМ на целевой базе и выбираем пункт Tasks\Detach (Задачи\Отсоединить):
7. В открывшемся окне ставим обе галочки и нажимаем ОК. После чего, МБД пропадет из списка:
8. Через обычный проводник заходим в каталог, где лежат нужные нам файлы. В нашем примере, это C:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS2012\MSSQL\DATA.
9. Копируем эти файлы в новый каталог на новый диск и снова открываем Microsoft SQL Server Management Studio.
10. Нажимаем ПКМ на разделе Databases (Базы данных), выбираем пункт Attach (Присоединить) и в открывшемся окне нажимаем кнопку Add (Добавить) и выбираем нужный нам файл RADIO-DB.mdf уже из нового каталога:
Убеждаемся, что пути у нас теперь новые и нажимаем ОК.
Всё, пользовательская база данных переехала на новый диск. Не нужно ничего перезапускать и т.д. Убеждаемся, что рабочие места переподключились к МБД и разрешаем им снова работать в штатном режиме.
Используем консоль
Экспорт
Для того, чтобы произвести экспорт, мы будем использовать утилиту mysqldump. При помощи нее осуществляется работа с текстовыми файлами базы данных. Итак, вы должны знать название базы данных, а также иметь доступ (логин и пароль) к аккаунту, который имеет, по крайней мере, доступ read only (только для чтения).
Для экспорта базы данных введите вот такую команду:
mysqldump -u имя_пользователя -p название_БД > data-dump.sql
в которой нужно ввести имя пользователя с необходимым доступом, название нужной вам базы данных, а также data-dump.sql – файл в текущей директории, куда будут сохранены данные.
![Как перенести файлы базы данных sql server в другой каталог или на другой диск [вики it-kb]](https://fuzeservers.ru/wp-content/uploads/b/c/7/bc70221364d5155492bdb8b2f807a5f6.jpeg)
После ввода этой команды вы не увидите никакого вывода на экране, однако вы можете проверить содержимое файла data-dump.sql для того, чтобы убедиться, что теперь он является резервной копией вашей базы данных.
Содержимое файла должно выглядеть примерно так, как показано ниже. В документе будет указано название базы данных (в данном случае MySQL), ее название и другие данные.
-- MySQL dump 10.13 Distrib 5.7.16, for Linux (x86_64) -- -- Host: localhost Database: database_name -- ------------------------------------------------------ -- Server version 5.7.16-0ubuntu0.16.04.1
Если во время процесса экспорта будут какие-нибудь ошибки, утилита mysqldump выведет на экран сообщение о них.
Импорт
Для того, чтобы импортировать существующий файл в MySQL или MariaDB, вам нужно начать с создания новой базы данных. Именно в нее вы затем загрузите содержимое резервной копии.
Сначала подключитесь к базе данных в качестве root-пользователя (либо другого пользователя, который сможет создать новую базу данных):
$ mysql -u root –p
После того, как вы подключились к консоли MySQL, создайте новую базу данных (в данном случае new_database):
mysql> CREATE DATABASE new_database;
После этого на экране появился следующий вывод:
Output Query OK, 1 row affected (0.00 sec)
Теперь для выхода из консоли MySQL нажмите CTRL+D. Далее переходите к самому импорту. Сделать это можно, введя вот такую команду:
$ mysql -u имя_пользователя -p new_database < data-dump.sql
Команда очень похожа на команду экспорта, вам нужно ввести имя пользователя, название новой базы данных, куда вы будете импортировать данные (в качестве примера new_database), и название самого файла, который вы собираетесь импортировать (data-dump.sql).
Если команда выполнена корректно, то никакого вывода на экране вы не увидите; на экране могут отобразиться только сообщения о каких-то ошибках. Как и в случае с экспортом, проверить, точно ли все прошло успешно, вы можете путем подключения к MySQL и просмотра данных. Сделать это можно, к примеру, используя команды USE и SHOW. Команда use определяет, какая база данных будет использоваться в дальнейших запросах. Введите:
mysql> use new_database
И тогда при всех последующих запросах в данном сеансе автоматически будет использоваться эта база данных. Данную установку можно изменить, использовав команду use с названием другой базы данных.
Что касается команды show, то она используется для того, чтобы посмотреть информацию о самих базах данных, о таблицах, столбцах, которые они содержат, а также о состоянии сервера.
Допустим, нам нужно посмотреть, список таблиц в базе. Для этого вводим:
mysql> SHOW TABLES;
Хотите увидеть список столбцов в какой-то определенной таблице? Используйте команду SHOW COLUMNS FROM и название нужно вам таблицы:
SHOW COLUMNS FROM название_таблицы
Статистику по работе сервера можно получить в ответ на команду:
mysql> SHOW GLOBAL STATUS;
Ресурсы, посвященные миграции
Для получения дополнительной помощи по выполнению этого сценария миграции см. следующий ресурс. Он был разработан как вспомогательный материал по задействованию объективно существующих проектов миграции.
| Заголовок | Описание |
|---|---|
| Модель и средство оценки рабочей нагрузки данных | Это средство предоставляет предлагаемые «оптимальные» целевые платформы, готовность к переходу в облако и уровень исправления приложения или базы данных для конкретной рабочей нагрузки. Оно обеспечивает простое и быстрое вычисление и создание отчетов, которое помогает ускорить оценку больших объемов, предоставляя, автоматизируя и унифицируя процесс принятия решения относительно целевой платформы. |
| Из MySQL в SQL Server — средство сравнения баз данных | Средство сравнения баз данных — это консольное приложение Windows, которое позволяет проверить идентичность данных на исходной и целевой платформах. Это средство можно использовать для эффективного сравнения данных на уровне строк или столбцов во всех или выбранных таблицах, строках и столбцах. |
Эти ресурсы разработали специалисты по разработке данных SQL. Основная задача этой команды — включить и ускорить комплексную модернизацию проектов миграции платформы данных на платформу данных Microsoft Azure.
Перенос самой системной базы данных master¶
Да, еще у нас осталась самая системная из всех системных баз — master — путь, прописанный для этой базы, будет путем по умолчанию для всех вновь создающихся баз на данном сервере. Впрочем, для пользователей Digispot это не очень актуально. Тем более, что мы уже умеем менять пути любым базам.
Итак, master:
1. Для изменения пути к БД master, нам понадобится оснастка SQL Server Configuration Manager (Диспетчер конфигурации SQL Server). Запускаем ее и открываем свойства SQL Server:
2. В свойствах SQL Server`а открываем вкладку Startup Parameters (Параметры запуска):
и по очереди меняем все указанные пути на новые. — каждая строка начинается со своего символа -d, -e или -l. Ни в коем случае не меняйте их и не удаляйте!
3. Каждое изменение пути подтверждаем нажатием кнопки Update.
4. Теперь останавливаем сервис, копируем файлы master.mdf и mastlog.ldf из старого каталога в новый. После чего запускам сервис. ERRORLOG можно не копировать. Он создастся заново.
Включение активной копии базы в DAG
В группе DAG только одна копия базы может быть активной. Таким образом, может возникнуть необходимость переключиться на другой сервер. Это делается в графическом интерфейсе или командной консоли Powershell.
Графический интерфейс
Конфигурация организации — Почтовый ящик — вкладка Управление базой данных — ставим указатель на нужную группу баз:
Ниже кликаем правой кнопкой по базе, которая находится на нужном нам сервере и выбираем Включить копию базы данных…:
В появившемся всплывающем окне выбираем параметр для автоматического переопределения активного сервера или оставляем в положении «Нет».
Powershell
Для смены активного сервера базы из группы DAG вводим:
* где ActivateOnServer указываем на целевой сервер, на котором должна быть активирована копия базы; MountDialOverride — параметр для автоматического подключения базы (возможны варианты: None, Lossless, GoodAvailability, BestAvailability, BestEffort); Confirm — требование от администратора вводить подтверждение перемещения активной копии (необходимо отключать для скриптов). В данном примере мы перемещаем активную копию базы DB5 на сервер SERVER15 без переопределения автоматического переноса сервера; консоль не потребует подтвердить наши намерения.
Конфигурация планировщика событий MySQL
Для выполнения всех запланированных событий MySQL использует специальный поток, который называется «поток планировщика событий».
Вы можете увидеть статус потока планировщика событий, выполнив следующую команду:
SHOW PROCESSLIST;
По умолчанию поток планировщика событий отключен. Чтобы включить его и запустить поток планировщика событий, необходимо выполнить следующую команду:
SET GLOBAL event_scheduler = ON;
Теперь, чтобы увидеть статус потока планировщика событий, снова выполните команду SHOW PROCESSLIST:
Чтобы отключить и остановить поток планировщика событий, выполняется команда SET GLOBAL со значением для event_scheduler OFF:
SET GLOBAL event_scheduler = OFF;
Перенос отключенных почтовых ящиков между базами
В данном примере мы рассмотрим ситуацию, когда у нас есть база от старого или другого сервера exchange, и мы должны перенести из нее все почтовые ящики в новую базу. Предположим, что база DAG01 — старая база, а DAG02 — новая.
Получаем список отключенных почтовых ящиков:
Get-MailboxDatabase -Identity «DAG01» | Get-MailboxStatistics | where {$_.DisconnectReason} | ft DisplayName,Identity,DisconnectReason
Необходимо подключить почтовый ящик к существующему пользователю Active Directory без почтового ящика. Имя пользователя должно совпадать с именем почтового ящика, иначе почтовый ящик будет переименован:
Connect-Mailbox -Identity «ca97f561-9b0b-4a83-a177-6f6261bdaa8c» -Database «DAG01» -User «Иванов Иван Иванович»
* где identity — Identity или DisplayName почтового ящика; user — аккаунт или DisplayName пользователя домена.
Для подключения почтового ящика к пользователю имеющему почтовый ящик, необходимо сначала отключить его текущий почтовый ящик:
Теперь можно перенести почтовый ящик в другую базу:
New-MoveRequest -Identity [email protected] -TargetDatabase «DAG02» -ArchiveTargetDatabase «DAG02» -BadItemLimit 10
Для перемещения нескольких пользователей сразу необходимо создать задание на перемещение с указанием CVS файла содержащего имена пользователей:
New-MigrationBatch -Local -AutoStart -AutoComplete -Name «MIgration task» -CSVData (::ReadAllBytes(«C:\User_list.csv»)) -TargetDatabases «DAG02» -BadItemLimit 10
Шаг 3 — Настройка правил контроля доступа AppArmor
Нам нужно сообщить AppArmor, чтобы он разрешил MySQL записывать в новую директорию. Это будет сделано посредством создания псевдонима между директорией по умолчанию и новым расположением. Чтобы сделать это, отредактируйте файл псевдонимов AppArmor:
sudo vim /etc/apparmor.d/tunables/alias
В конце этого файла добавьте следующее правило псевдонимов:
alias /var/lib/mysql/ -> /home/mial/mysql/,
Чтобы изменения вступили в силу, перезапустите AppArmor:
sudo systemctl restart apparmor
Примечание: если вы пропустите шаг настройки AppArmor вы придёте к следующему сообщению об ошибке:
Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.
Вывод для systemctl и journalctl заканчивается:
Jul 18 11:03:24 ubuntu-512mb-nyc1-01 systemd: mysql.service: Main process exited, code=exited, status=1/FAILURE
Поскольку сообщение не приносит ясности о связи между AppArmor и директорией data, на решение этой ошибки можно потерять время.
Шаг 1 — Перемещение директории Data MySQL
Подготавливаясь для перемещения директории MySQL data, давайте проверим текущее расположения, для этого запустите интерактивную сессию MySQL с учётными данными администратора.
mysql -u root -p
Когда появится запрос, введите пароль рута MySQL. Затем в приглашении MySQL выполните запрос для показа текущего расположения директории data:
select @@datadir;
+-----------------+ | @@datadir | +-----------------+ | /var/lib/mysql/ | +-----------------+ 1 row in set (0.00 sec)
Этот вывод подтверждает, что MySQL настроена на использование директории data по умолчанию, /var/lib/mysql/, т.е. эту директорию нам и нужно перемещать. После подтверждения этого, напечатайте exit; для выхода.
Чтобы быть уверенными в целостности данных, вы отключим MySQL перед тем, как начнём делать наши изменения:
sudo systemctl stop mysql
systemctl не показывает результат выполнения команды управления сервисом, поэтому если вы хотите убедиться, что всё прошло успешно, используйте следующую команду:
sudo systemctl status mysql
Теперь, когда сервер отключён, мы скопируем с rsync существующую директорию с базой данных в новое расположение. Использование флага -a сохраняет права доступа и другие свойства каталога, -v обеспечивает вербальный вывод, поэтому вы можете следить за прогрессом.
Внимание: убедитесь, что отсутствуют завершающие слеши после имён директорий, они могут появиться при использовании автозавершения по tab. Когда присутствует завершающий слеш, rsync сбросит содержимое директории в точку монтирования вместо перенесения директории mysql.
sudo rsync -av /var/lib/mysql /home/mial
Когда rsync закончит, переименуйте текущую папку, добавив к её имени расширение .bak и сохраните её до тех пор, пока не подтвердится, что перемещение было успешным. Переименовывая папку, мы с одной стороны убедимся, что сервер точно работает с новым расположением, при этом мы сохраним резервную копию на случай, если что-то пошло не так:
sudo mv /var/lib/mysql /var/lib/mysql.bak
Теперь мы готовы переключиться на настройку.
