# DDL Execution
__*owner role*__
__*worker*__
__*load schema*__
__*start job*__
__*online DDL*__

![left](./student-guide/diagram/DDLExecution01_aa_002_20220512.png)

------------------------------------------------------------
TiDB database supports online DDL, that is, DDL operations do not lock tables, and DML statements are not blocked. Next, let's take a look at the various modules required to execute DDL.

First, the entire TiDB database allows only one TiDB Server to perform DDL operations at the same time. Every TiDB Server has a worker module that handles DDL operations and is enabled only if the current TiDB Server role is owner.

If you have more than one TiDB Server in your TiDB database, then these TiDB Servers will take turns to become the owner role according to a fixed time (by elect). This time is called a term of office. When a TiDB Server is the owner role and is in the term of office, its worker model The block can then handle DDL operations.

The current owner role information of the database is persisted in PD, and the woker module can check whether the TiDB server in which it is located is currently the ownere role. When the term of owner expires, PD will initiate and be responsible for selecting a new owner.

Secondly, in addition to the worker module, there is also a load schema module, which is used to load the latest schema information after the current TiDB Server becomes the ownere role, so that the TiDB Server with the current owner role has the latest schema information.

Finally, the start job module is responsible for receiving DDL request and assigning IDs to DDL operations. Here we call each DDL operation assigned an ID a job.

In summary, the first part of the DDL operation can be summarized as follows:

1. The DDL statement is sent from the client to the TiDB Server, which parses (parse) and compiles (Compile) to generate an execution plan. This procedure is the same as for DML statements, see DML statements here.

2. The start job module encapsulates DDL operations and persist them into TiKV. After that, the start job will also do a job, which is to inform the worker module of the TiDB server where it is located to execute the job in TiKV. Therefore, the worker first determines whether the TiDB server on which he is located is the owner role, and if it is, it will be executed, and if not, give up.

3. If the TiDB Server where the start job is located in the previous step is not the owner role, then we can only wait for the TiDB Server with the owner role in the TiDB database to periodically check that there are jobs in TiKV that need to be executed, and then the job will be processed.