# Inventorying the Source Environment

__*Source Environment*__

+ Key considerations for the source database to be migrated:
  + Ensure that you have the supported versions and configurations.
  + Ensure that you have sufficient permissions to export the data.
  + Determine the workload level.
  + Check the environment variables that have been set in the source database.
  + Check the database character set.
  + Determine the disaster recovery plan that is currently in place.
------------------------------------------------------------------------------
Inventorying the environment includes tasks such as ensuring that you have the supported `On-Premises MySQL / MariaDB` versions and configurations.
- Ensure that you have the supported versions and configurations.
  - At a minimum, you should have at least `MySQL5.7` or `MariaDB10.2`.
  - `FULLTEXT` and `SPATIAL` data types are currently not supported in `TiDB Cloud`.
  - `TiDB` contains the following system databases by default: `INFORMATION_SCHEMA`, `PERFORMANCE_SCHEMA`, `mysql`, `sys`, and `test`. When you do migration task, you need to filter out these system databases instead of using the default % to select the migration object. Otherwise, you will try to migrate these system databases from the source database to the target `TiDB`, which will cause the task to fail. To avoid this issue, it is recommended to fill in the specific database and table names.
- Ensure that you have sufficient permissions to export the data.
  - We required privileges：
    - `SELECT`: Required when exporting tables.
    - `RELOAD`: Required when using consistency flush. Note that only `TiDB` supports this privilege. When the upstream is an RDS database or a managed service, you can ignore this privilege.
    - `LOCK TABLES`: Required when using consistency lock. This privilege must be granted for all the databases and tables to be exported.
    - `REPLICATION CLIENT`: Required when exporting metadata to record data snapshot.
    - `REPLICATION SLAVE`: reads the binlog for incremental replication.

- Determine the size of the source database's database files.
  - You can find the total size of the database files of the database that you plan to migrate, including redo log files sizes and undo file sizes, by executing the du -s command at the command line.
    - Example:
      ```
      du -s/mydb/*
      ```
        - This value provides information about how much space to allocate for the target database system. Check the name and sizes of data files by querying the `INFORMATION_SCHEMA.FILES` dynamic views.
- Determine the workload level.
  - You can find a sample of the workload for the source database by `MySQL Enterprise Monitor` or `PMM`. Alternatively, The performance monitor statistics, operating system statistics, and wait events provide a relatively clear measure of the workload in terms of the operating system capacity.
 - Determine the environment variables that have been set in the source database
  - you need to turn on the binary log of the source MySQL / MariaDB set the binlog_format parameter to ROW, otherwise we can not do the incremental replication.
- Check the database character set.
  - You can find the database character set by issuing the following query：
    - show variables like '%character%';
	  - show variables like 'collation%';
	  - show create database <database name>;
	  - show create table <table name>;
	  - show show full columns from <table name>;
  - You will need to ensure that the target database will also have this character set.
  - Check and ensure that the source database uses collations that are compatible with `TiDB`. The default collation for the `utf8mb4` character set in `TiDB` is `utf8mb4_bin`. But in `MySQL 8.0`, the default collation is `utf8mb4_0900_ai_ci`. If the upstream `On-Premises MySQL / MariaDB` uses the default collation, because `TiDB` is not compatible with `utf8mb4_0900_ai_ci`. To resolve this problem, you need to modify the collation of the source database to `utf8mb4_bin` before the migration. For a complete list of `TiDB` supported character sets and collations, see https://docs.pingcap.com/tidb/stable/character-set-and-collation.
- Determine the disaster recovery plan that is currently in place.
  - For example, if `On-Premises MySQL / MariaDB` slave is already deployed, you can create a slave for the migration procedure. (This migration solution will use slave for the migration.)