content_image/742448.jpg
More columns on the replica.  The following table definitions are valid and replicate correctly: 

source> CREATE TABLE t1 (c1 INT, c2 INT); replica> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT); 

The following definitions raise an error because the columns common to both versions of the table are not defined in the same order on both the source and the replica: 

source> CREATE TABLE t1 (c1 INT, c2 INT); replica> CREATE TABLE t1 (c2 INT, c1 INT, c3 INT); 

The following table definitions also raise an error because the definition for the extra column in the replica’s version of the table appears before the definitions for the columns which are common to both versions of the table: 

source> CREATE TABLE t1 (c1 INT, c2 INT); replica> CREATE TABLE t1 (c3 INT, c1 INT, c2 INT); 

The following table definitions fail because the replica’s version of the table has additional columns compared to the source’s version, and the two versions of the table use different data types for the common column c2 : 

## Replication of Columns Having Different Data Types 

source> CREATE TABLE t1 (c1 INT, c2 BIGINT); replica> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT); 

Corresponding columns on the source’s and the replica’s copies of the same table ideally should have the same data type. However, this is not always strictly enforced, as long as certain conditions are met. 

It is usually possible to replicate from a column of a given data type to another column of the same type and same size or width, where applicable, or larger. For example, you can replicate from a CHAR(10) column to another CHAR(10) , or from a CHAR(10)  column to a CHAR(25)  column without any problems. In certain cases, it also possible to replicate from a column having one data type (on the source) to a column having a different data type (on the replica); when the data type of the source’s version of the column is promoted to a type that is the same size or larger on the replica, this is known as attribute promotion . 

Attribute promotion can be used with both statement-based and row-based replication, and is not dependent on the storage engine used by either the source or the replica. However, the choice of logging format does have an effect on the type conversions that are permitted; the particulars are discussed later in this section. 

<img src='content_image/742448.jpg'>

## Important 

Whether you use statement-based or row-based replication, the replica’s copy of the table cannot contain more columns than the source’s copy if you wish to employ attribute promotion. 

Statement-based replication.  When using statement-based replication, a simple rule of thumb to follow is, “If the statement run on the source would also execute successfully on the replica, it should also replicate successfully” . In other words, if the statement uses a value that is compatible with the type of a given column on the replica, the statement can be replicated. For example, you can insert any value that fits in a TINYINT  column into a BIGINT  column as well; it follows that, even if you change the type of a TINYINT  column in the replica’s copy of a table to BIGINT , any insert into that column on the source that succeeds should also succeed on the replica, since it is impossible to have a legal TINYINT  value that is large enough to exceed a BIGINT  column. 

