Chapter 3. Deploying MySQL Enterprise Service Manager
The last line provides the information about how to connect to the server using the standard mysql command line client.
All the MySQL Enterprise Monitor repository information, including your
configuration, rule and historical data is stored within the
mem database.
To backup this information using mysqldump you
might use the following command:
shell> mysqldump --single-transaction » -uservice_manager -pPassword -P13306 -h127.0.0.1 mem >mem.dump
The above command would create a file,
mem.dump, containing all of the MySQL Enterprise Monitor
data.
To ensure consistency in a recovery situation, you may also want to backup the agent configuration and metadata stored on each monitored MySQL server. To do this:
Backup the configuration files of each agent. You should keep a copy of the
etcdirectory for each agent. This directory contains the main configuration file,mysql-monitor-agent.ini, and the configuration information for each server being monitored, which is stored within theetc/instancesdirectory.On each server being monitored, retain a copy of the
mysql.inventorytable, which contains the unique ID of the MySQL server.
You can migrate the data generated during a MySQL Enterprise Monitor 1.3.x installation using the Data Migration functionality of the Server Configuration panel.
To use the data migration feature, you must have installed MySQL Enterprise Service Manager using an update installer. The update installer performs the initial migration of your configuration, rules, schedule, and events data. The historical data is not migrated until you explicitly request the migration of information within the Manage Servers section of the Settings panel.
Data migration works on a single server, allowing you to select on which servers you want to migrate information. The migration is subject to the following:
You must elect to migrate the data from each server individually.
Migration takes approximately 5-6 hours, for each month, for each server. Therefore, if you have six months of data on 10 servers it could take between 300 and 360 hours (15 days) to migrate all of your historical data one server at a time.
To limit the data migration, set the Data Purge Behavior within the Settings page. Only data more recent than the specified purge period will be migrated. Data older than the purge period will be ignored.
To prevent performance issues, migrate only one or a small number of servers concurrently.
You can start and stop the migration of the data at any time. As a general guide, you should avoid stopping the data migration process and allow it to complete unless:
Run out of disk space.
MySQL Enterprise Service Manager becomes too slow and unresponsive.
Migration never completes.
With the last item, where the migration never completes, occasionally there are some aspects of the data that cannot be migrated successfully. This will prevent the migration process completing, but does not affect the conversion of any data that could be migrated.
Starting Historical Data Migration
To start data migration:
Switch to the Manage Servers display of the Settings panel within MySQL Enterprise Dashboard.
Ensure that the data migration functionality has been enabled. The and buttons next to Historical Data Migration will be visible.
Select the servers you want to migrate by using the checkbox next to each server name. You can select one or more servers to migrate. Servers that are suitable for migration will show their migration status within the Migration Status columnn. If the server is not able to be migrated,
N/Awill be shown.Click next to Historical Data Migration.
You will be presented with a confirmation dialog box. To start the migration, click . To cancel migration, click .
The servers that have been selected for migration will show
Queued for Migrationin the Migration Status column.
Monitoring Historical Data Migration
You can check the migration status of any individual server by examining the Migration Status column for each server. You can see an example of the migration status below.
Note that the migration status is shown according to the state of migration at the time the page was loaded. The actual migration continues in the background, and the current state may not match the state of the migration at the time it is viewed.
Servers showing Done in the Migration
Status column have already completed their migration.
You can check the overall migration status by examining the Upgrade Status display.
Stopping Historical Data Migration
You can stop the migration process for any server that is still migrating data. The migration can be restarted at any time without causing any problems.
To stop the historical data migration:
Select the servers you want to stop migrating by using the checkbox next to each server name. You can select one or more servers to stop migrating.
Click next to Historical Data Migration.
Confirmation that the migration has been stopped will be provided. If migration has already completed, you will be notified.
Removing Old Data
Once data migration has been completed for all the servers you
want to migrate, you may want to delete or remove access to the
old data within your MySQL Enterprise Monitor repository. Data for MySQL Enterprise Monitor 1.3
was stored in a database called merlin within
the MySQL repository. Data for MySQL Enterprise Monitor 2.0 is stored within a
database called mem.
To create a backup of the old information, use mysqldump:
shell> mysqldump -uservice_manager -pPassword -P13306 -h127.0.0.1 merlin >data-1.3.sql
The above will create a file, data-1.3.sql
containg all of the MySQL Enterprise Monitor 1.3 information.
If you remove access to the old data, then the data migration
options for old servers will be removed from the Manage
Servers panel within MySQL Enterprise Service Manager. To remove access,
you need to REVOKE access to the
merlin database:
mysql& REVOKE ALL on merlin.* FROM 'service_manager';
Note that revoking access to the old data will not reclaim any of the disk space used by the old data.
To delete the data from the database and free up the space being
used by the historical information, DROP the
merlin database:
mysql& DROP DATABASE merlin;
Once all the data has been migrated you can hide the migration user interface by clicking on the button.
MySQL Enterprise Monitor is generally self managing and does not need excessive maintenance. You should, however, be aware of certain maintentnace tasks that you can automate or will need to manually perform to keep your MySQL Enterprise Monitor running efficiently.
Make sure you have set the purge interval for your data to an appropriate value according to durationa nd history of data that you want to keep. For more information, see ???.
Check, and delete, the contents of the temporary directory with your MySQL Enterprise Service Manager installation directory.
Running MySQL Enterprise Service Manager places a reasonable load on your system, and this load increases linearly as you add more agents monitoring more servers. Ideally, you should use a dedicated machine for MySQL Enterprise Service Manager, rather than running it alongside other applications and services.
Minimum System Requirements
2 or more CPU cores
2 or more GB of RAM
Disk I/O subsystem applicable for a write-intensive database
Recommended System Requirements (if monitoring 100 or more MySQL servers)
4 or more CPU cores
8 or more GB of RAM
Disk I/O subsystem applicable for a write-intensive database (RAID10, RAID 0+1)