anchor.diff:        "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004"
       },
       "op": "u", // <4>
  -    "ts_ms": 1465581029523 // <5>
  +    "ts_ms": 1465581029523 
     }
   }
   ----
   
  -Comparing this to the value in the _insert_ event, you can see a couple of differences in the `payload` section:
  -
  -<1> The `before` field now has the state of the row with the values before the database commit.
  -<2> The `after` field now has the updated state of the row, and the `first_name` value is now `Anne Marie`. You can compare the `before` and `after` structures to determine what actually changed in this row because of the commit.
  -<3> The `source` field structure has the same fields as before, but the values are different (this event is from a different position in the binlog). The `source` structure shows information about MySQL’s record of this change (providing traceability). It also has information you can use to compare to other events in this and other topics to know whether this event occurred before, after, or as part of the same MySQL commit as other events.
  -<4> The `op` field value is now `u`, signifying that this row changed because of an update.
  -<5> The `ts_ms` field shows the timestamp when {prodname} processed this event.
  +.Descriptions of _update_ event value fields
  +[cols="1,2,7",options="header"]
  +|===
  +|Item |Field name |Description
  +
  +|1
  +|`before`
  +|An optional field that specifies the state of the row before the event occurred. In an _update_ event value, the `before` field contains a field for each table column and the value that was in that column before the database commit. In this example, the `first_name` value is `Anne.`
  +
  +|2
  +|`after`
  +| An optional field that specifies the state of the row after the event occurred. You can compare the `before` and `after` structures to determine what the update to this row was. In the example, the `first_name` value is now `Anne Marie`. 
  +
  +|3
  +|`source`
  +a|Mandatory field that describes the source metadata for the event. The `source` field structure has the same fields as in a _create_ event, but some values are different, for example, the sample _update_ event is from a different position in the binlog. The source metadata includes: 
  +
  +* {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. In an _update_ event value, the `op` field value is `u`, signifying that this row changed because of an update.
  +
  +|===
   
   [NOTE]
   ====
  -When the columns for a row’s primary or unique key are updated, the value of the row’s key is changed and {prodname} outputs three events: a _DELETE_ event and tombstone event with the old key for the row, followed by an _INSERT_ event with the new key for the row.
  +Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, {prodname} outputs _three_ events: a `DELETE` event and a {link-prefix}:{link-mysql-connector}#mysql-tombstone-events[tombstone event] with the old key for the row, followed by an event with the new key for the row. Details are in the next section. 
   ====
   
  -=== Delete change event value
  -
  -The value of a _delete_ change event on the `customers` table has the exact same schema as _create_ and _update_ events. The payload is structured the same, but holds different values. Here is an example (formatted for readability):
  -
  +[id="mysql-primary-key-updates"]
  +=== Primary key updates
  +
  +An `UPDATE` operation that changes a row's primary key field(s) is known
  +as a primary key change. For a primary key change, in place of sending an `UPDATE` event record, the connector sends a `DELETE` event record for the old key and a `CREATE` event record for the new (updated) key. These events have the usual structure and content, and in addition, each one has a message header related to the primary key change: 
  +
  +* The `DELETE` event record has `__debezium.newkey` as a message header. The value of this header is the new primary key for the updated row.
  +
  +* The `CREATE` event record has `__debezium.oldkey` as a message header. The value of this header is the previous (old) primary key that the updated row had.
  +
  +[id="mysql-delete-events"]
  +=== _delete_ events
  +
  +The value in a _delete_ change event has the same `schema` portion as _create_ and _update_ events for the same table. The `payload` portion in a _delete_ event for the sample `customers` table looks like this:  
   
   [source,json,options="nowrap",subs="+attributes"]
   ----
  
positive.code:           }
          ],
          "optional": true,
          "name": "mysql-server-1.inventory.customers.Value",
          "field": "before"
        },
        {
  
negative.code: ) AUTO_INCREMENT=1001;
  ----
  
  The value portion of a change event for a change to this table is described for each event type: 
  
  * <<mysql-create-events,_create_ events>>
  * <<mysql-update-events,_update_ events>>
  * <<mysql-delete-events,_delete_ events>>
  
  [id="mysql-create-events"]
  === _create_ events
  
  The following example shows the value portion of a change event that the connector generates for an operation that creates data in the `customers` table: 
  
  [source,json,options="nowrap",subs="+attributes"]
  ----
  