anchor.diff:  }
   ----
   
  -Comparing the `payload` portion to the payloads in the _create_ and _update_ events, you can see some differences:
  -
  -<1> The `before` field now has the state of the row that was deleted with the database commit.
  -<2> The `after` field is `null`, signifying that the row no longer exists.
  -<3> The `source` field structure has many of the same values as before, except the `ts_sec` and `pos` fields have changed (and the file might have changed in other scenarios).
  -<4> The `op` field value is now `d`, signifying that this row was deleted.
  -<5> The `ts_ms` shows the timestamp when {prodname} processed this event.
  -
  -This event provides a consumer with the information that it needs to process the removal of this row. The old values are included because some consumers might require them in order to properly handle the removal.
  -
  -The MySQL connector’s events are designed to work with link:{link-kafka-docs}#compaction[Kafka log compaction], which allows for the removal of some older messages as long as at least the most recent message for every key is kept. This allows Kafka to reclaim storage space while ensuring the topic contains a complete data set and can be used for reloading key-based state.
  -
  -When a row is deleted, the _delete_ event value listed above still works with log compaction, because Kafka can still remove all earlier messages with that same key. If the message value is `null`, Kafka knows that it can remove all messages with that same key. To make this possible, {prodname}’s MySQL connector always follows a _delete_ event with a special tombstone event that has the same key but a `null` value.
  -
  -== Primary Key Update Header
  -
  -When there is an update event that's changing the row's primary key field/s, also known
  -as a primary key change, Debezium will in that case send a DELETE event for the old key
  -and an INSERT event for the new (updated) key.
  -
  -The DELETE event produces a Kafka message which has a message header `__debezium.newkey`
  -and the value is the new primary key.
  -
  -The INSERT event produces a Kafka message which has a message header `__debezium.oldkey`
  -and the value is the previous (old) primary key of the updated row.
  +.Descriptions of _delete_ event value fields
  +[cols="1,2,7",options="header"]
  +|===
  +|Item |Field name |Description
  +
  +|1
  +|`before`
  +|Optional field that specifies the state of the row before the event occurred. In a _delete_ event value, the `before` field contains the values that were in the row before it was deleted with the database commit.
  +
  +|2
  +|`after`
  +| Optional field that specifies the state of the row after the event occurred. In a _delete_ event value, the `after` field is `null`, signifying that the row no longer exists.
  +
  +|3
  +|`source`
  +a|Mandatory field that describes the source metadata for the event. In a _delete_ event value, the `source` field structure is the same as for _create_ and _update_ events for the same table. Many `source` field values are also the same. In a _delete_ event value, the `ts_ms` and `pos` field values, as well as other values, might have changed. But the `source` field in a _delete_ event value provides the same metadata: 
  +
  +* {prodname} version
  +* Connector name
  +* binlog name where the event was recorded
  +* binlog position
  +* Row within the event
  +* If the event was part of a snapshot
  +* Name of the database and table that contain the updated row
  +* ID of the MySQL thread that created the event (non-snapshot only)
  +* MySQL server ID (if available)
  +* Timestamp
  +
  +If the {link-prefix}:{link-mysql-connector}#enable-query-log-events-for-cdc_{context}[`binlog_rows_query_log_events`] MySQL configuration option is enabled and the connector configuration `include.query` property is enabled, the `source` field also provides the `query` field, which contains the original SQL statement that caused the change event.
  +
  +|4
  +|`op`
  +a|Mandatory string that describes the type of operation. The `op` field value is `d`, signifying that this row was deleted.
  +
  +|5
  +|`ts_ms`
  +a|Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task.
  +
  +|===
  +
  +A _delete_ change event record provides a consumer with the information it needs to process the removal of this row. The old values are included because some consumers might require them in order to properly handle the removal.
  +
  +MySQL connector events are designed to work with link:https://kafka.apache.org/documentation/#compaction[Kafka log compaction]. Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state.
  +
  +[id="mysql-tombstone-events"]
  +.Tombstone events
  +When a row is deleted, the _delete_ event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be `null`. To make this possible, {prodname}’s MySQL connector follows a _delete_ event with a special tombstone event that has the same key but a `null` value.
  
positive.code:   }
  }
  ----
  <1> The `schema` describes what is in the `payload`.
  <2> The `mysql-server-1.inventory.customers.Key` is the name of the schema which defines the structure where `mysql-server-1` is the connector name, `inventory` is the database, and `customers` is the table.
  <3> Denotes that the `payload` is not optional.
  <4> Specifies the type of fields expected in the `payload`.
  <5> The payload itself, which in this case only contains a single `id` field.
  
  This key describes the row in the `inventory.customers` table which is out from the connector entitled `mysql-server-1` whose `id` primary key column has a value of `1001`.
  =====
  
  == Change event value
  
  The change event value contains a schema and a payload section. There are three types of change event values which have an envelope structure. The fields in this structure are explained below and marked on each of the change event value examples.
  
  * <<Create change event value>>
  * <<Update change event value>>
  * <<Delete change event value>>
  
  [cols="1,2,7"]
  |===
  |Item |Field name |Description
  
  |1
  | `name`
  | `mysql-server-1.inventory.customers.Key` is the name of the schema which defines the structure where `mysql-server-1` is the connector name, `inventory` is the database and `customers` is the table
  
  |2
  |`op`
  a| A *mandatory* string that describes the type of operation.
  
  .values
  * `c` = create
  * `u` = update
  * `d` = delete
  * `r` = read (_initial snapshot_ only)
  
  |3
  |`before`
  | An optional field that specifies the state of the row before the event occurred.
  
  |4
  |`after`
  | An optional field that specifies the state of the row after the event occurred.
  
  |5
  |`source`
  a| A *mandatory* field that describes the source metadata for the event including:
  
  * the {prodname} version
  * the connector name
  * the binlog name where the event was recorded
  * the binlog position
  * the row within the event
  * if the event was part of a snapshot
  * the name of the affected database and table
  * the id of the MySQL thread creating the event (non-snapshot only)
  * the MySQL server ID (if available)
  * timestamp
  
  NOTE: If the {link-prefix}:{link-mysql-connector}#enable-query-log-events-for-cdc_{context}[binlog_rows_query_log_events] option is enabled and the connector has the `include.query` option enabled, a `query` field is displayed which contains the original SQL statement that generated the event.
  
  |6
  |`ts_ms`
  a| An optional field that displays the time at which the connector processed the event.
  
  NOTE: The time is based on the system clock in the JVM running the Kafka Connect task.
  
  |===
  
  Let us look at an example table and then how the schema and payload would appear for the table.
  
  .example table
  [source,sql]
  ----
  CREATE TABLE customers (
  
negative.code:           }
          ],
          "optional": true,
          "name": "mysql-server-1.inventory.customers.Value", // <2>
          "field": "before"
        },
        {
  