16.4.1.9. Репликация с Отличающимися Табличными Определениями на Ведущем устройстве и Ведомом устройстве

Исходные и целевые таблицы для репликации не должны быть идентичными. Таблица на ведущем устройстве может иметь больше или меньше столбцов чем копия ведомого устройства таблицы. Кроме того, соответствующие столбцы таблицы на ведущем устройстве и ведомом устройстве могут использовать различные типы данных согласно определенным условиям.

Во всех случаях, где у исходных и целевых таблиц нет идентичных определений, имена базы данных и имена таблиц должны быть тем же самым и на ведущем устройстве и на ведомом устройстве. Дополнительные условия обсуждаются, с примерами, в следующих двух разделах.

16.4.1.9.1. Репликация с Большим количеством Столбцов на Ведущем устройстве или Ведомом устройстве

Можно тиражировать таблицу от ведущего устройства к ведомому устройству так, что, у основных и ведомых копий таблицы есть отличающиеся числа столбцов согласно следующим условиям:

Столбцы, характерные для обеих версий таблицы, должны быть определены в том же самом порядке на ведущее устройство и ведомое устройство.

(Это - истина, даже если у обеих таблиц есть то же самое число столбцов.)
Столбцы, характерные для обеих версий таблицы, должны быть определены перед любыми дополнительными столбцами.

Это означает то выполнение ALTER TABLE оператор на ведомом устройстве, где новый столбец вставляется в таблицу в пределах диапазона столбцов, характерных для обеих таблиц, заставляет репликацию перестать работать, как показано в следующем примере:

Предположите что таблица t, существующий на ведущем устройстве и ведомом устройстве, определяется следующим CREATE TABLE оператор:
```
CREATE TABLE t (    c1 INT,    c2 INT,    c3 INT); 
```
Предположите что ALTER TABLE оператор, показанный здесь, выполняется на ведомом устройстве:
```
ALTER TABLE t ADD COLUMN cnew1 INT AFTER c3;
```
Предыдущее ALTER TABLE разрешается на ведомом устройстве потому что столбцы c1, c2, и c3 это характерно для обеих версий таблицы t останьтесь группировался в обеих версиях таблицы, перед любыми столбцами, которые отличаются.

Однако, следующий ALTER TABLE оператор не может быть выполнен на ведомом устройстве, не заставляя репликацию повредиться:
```
ALTER TABLE t ADD COLUMN cnew2 INT AFTER c2;
```
Сбои репликации после выполнения на ведомом устройстве ALTER TABLE оператор, только показанный, потому что новый столбец cnew2 прибывает между столбцами, характерными для обеих версий t.
У каждого "дополнительного" столбца в версии таблицы, имеющей больше столбцов, должно быть значение по умолчанию.

Значение по умолчанию столбца определяется многими факторами, включая его тип, определяется ли оно с помощью a DEFAULT опция, объявляется ли это как NULL, и режим SQL сервера в действительности во время его создания; для получения дополнительной информации см. Раздел 11.5, "Значения по умолчанию Типа данных").

Кроме того, когда у копии ведомого устройства таблицы есть больше столбцов чем копия ведущего устройства, каждый столбец, характерный для таблиц, должен использовать тот же самый тип данных в обеих таблицах.

Примеры. Следующие примеры иллюстрируют некоторые допустимые и недопустимые табличные определения:

Больше столбцов на ведущем устройстве. Следующие табличные определения допустимы и тиражируются правильно:

master> CREATE TABLE t1 (c1 INT, c2 INT, c3
            INT);slave>  CREATE TABLE t1 (c1 INT, c2
            INT);

Следующие табличные определения повысили бы Ошибку 1532 (ER_BINLOG_ROW_RBR_TO_SBR) потому что определения столбцов, характерных для обеих версий таблицы, находятся в различном порядке на ведомое устройство, чем они находятся на ведущем устройстве:

master> CREATE TABLE t1 (c1 INT, c2 INT, c3
            INT);slave>  CREATE TABLE t1 (c2 INT, c1
            INT);

Следующие табличные определения также повысили бы Ошибку 1532, потому что определение дополнительного столбца на ведущем устройстве появляется перед определениями столбцов, характерных для обеих версий таблицы:

master> CREATE TABLE t1 (c3 INT, c1 INT, c2
            INT);slave>  CREATE TABLE t1 (c1 INT, c2
            INT);

Больше столбцов на ведомом устройстве. Следующие табличные определения допустимы и тиражируются правильно:

master> CREATE TABLE t1 (c1 INT, c2 INT);slave>  CREATE TABLE t1 (c1 INT, c2 INT, c3
            INT);

Следующие определения повышают Ошибку 1532, потому что столбцы, характерные для обеих версий таблицы, не определяются в том же самом порядке и на ведущее устройство и на ведомое устройство:

master> CREATE TABLE t1 (c1 INT, c2 INT);slave>  CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);

Следующие табличные определения также повышают Ошибку 1532, потому что определение для дополнительного столбца в версии ведомого устройства таблицы появляется перед определениями для столбцов, которые характерны для обеих версий таблицы:

master> CREATE TABLE t1 (c1 INT, c2 INT);slave>  CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);

Следующие табличные определения перестали работать, потому что у версии ведомого устройства таблицы есть дополнительные столбцы по сравнению с версией ведущего устройства, и две версии таблицы используют различные типы данных для общего столбца c2:

master> CREATE TABLE t1 (c1 INT, c2
            BIGINT);slave>  CREATE TABLE t1 (c1 INT, c2 INT, c3
            INT);

16.4.1.9.2. Репликация Столбцов, Имеющих Различные Типы данных

У соответствующих столбцов на ведущем устройстве и копии ведомого устройства той же самой таблицы идеально должен быть тот же самый тип данных. Однако, начинаясь с MySQL 5.1.21, это не всегда строго осуществляется, пока определенные условия соблюдаются.

При прочих равных условиях всегда возможно тиражироваться от столбца типа определенных данных к другому столбцу того же самого типа и того же самого размера или width, где применимый, или больше. Например, можно тиражироваться от a CHAR(10) столбец другому CHAR(10), или от a CHAR(10) столбец к a CHAR(25) столбец без любых проблем. В определенных случаях, это также возможный тиражироваться от столбца, имеющего один тип данных (на ведущем устройстве) к столбцу, имеющему различный тип данных (на ведомом устройстве); когда типу данных версии ведущего устройства столбца способствуют на тип, который является тем же самым размером или больше на ведомом устройстве, это известно как продвижение атрибута.

Продвижение атрибута может использоваться и с основанной на операторе и с построчной репликацией, и не зависит от механизма хранения, используемого или ведущим устройством или ведомым устройством. Однако, выбор журналирования формата действительно имеет эффект на преобразования типов, которые разрешаются; подробные сведения обсуждаются позже в этом разделе.

Важный

Используете ли Вы основанную на операторе или построчную репликацию, копия ведомого устройства таблицы не может содержать больше столбцов чем копия ведущего устройства, если Вы хотите использовать продвижение атрибута.

Основанная на операторе репликация. При использовании основанной на операторе репликации простое эмпирическое правило, чтобы следовать, "Если бы оператор, на котором работают, ведущее устройство также выполнилось бы успешно на ведомом устройстве, это должно также тиражироваться успешно". Другими словами, если оператор использует значение, которое является совместимым с типом данного столбца на ведомом устройстве, оператор может быть тиражирован. Например, можно вставить любое значение, которое помещается в a TINYINT столбец в a BIGINT столбец также; из этого следует, что, даже если Вы изменяете тип a TINYINT столбец в копии ведомого устройства таблицы к BIGINT, любой вставляет в тот столбец на ведущем устройстве, которое успешно выполняется, должен также успешно выполниться на ведомом устройстве, так как невозможно иметь юридическое TINYINT значение, которое является достаточно большим, чтобы превысить a BIGINT столбец.

До MySQL 5.6.10, при использовании основанной на операторе репликации, AUTO_INCREMENT столбцы были обязаны быть тем же самым и на ведущем устройстве и на ведомом устройстве; иначе, обновления могли быть применены к неправильной таблице на ведомом устройстве. (Ошибка #12669186)

Построчная репликация: продвижение атрибута и понижение в должности. Построчная репликация в MySQL 5.6 поддерживает продвижение атрибута и понижение в должности между меньшими типами данных и большими типами. Также возможно определить, разрешить ли (усеченные) или преобразования нес потерями с потерями пониженных в должности значений столбцов, как объяснено позже в этом разделе.

Преобразования нес потерями и с потерями. Когда целевой тип не может представить вставляемое значение, решение должно быть принято о том, как обработать преобразование. Если мы разрешаем преобразование, но усеченный (или иначе изменяем), исходное значение, чтобы достигнуть "подгонки" в целевом столбце, мы делаем то, что известно как преобразование с потерями. Преобразование, которое не требует, чтобы усечение или подобные модификации приспособили исходное значение столбца в целевом столбце, является преобразованием нес потерями.

Режимы преобразования типов (slave_type_conversions переменная). Установка slave_type_conversions глобальная переменная сервера управляет режимом преобразования типов, используемым на ведомом устройстве. Эта переменная принимает ряд значений от следующей таблицы, которая показывает эффекты каждого режима на поведении преобразования типов ведомого устройства:

Режим	Эффект
`ALL_LOSSY`	В этом режиме разрешаются преобразования типов, которые означали бы потерю информации. Это не подразумевает, что преобразования нес потерями разрешаются, просто что только случаи, требующие или преобразования с потерями или никакое преобразование вообще, разрешаются; например, включение только этот режим разрешает `INT` столбец, который будет преобразован в `TINYINT` (преобразование с потерями), но не a `TINYINT` столбец к `INT` столбец (нес потерями). Попытка последнего преобразования в этом случае заставила бы репликацию останавливаться с ошибкой на ведомом устройстве.
`ALL_NON_LOSSY`	Этот режим разрешает преобразования, которые не требуют усечения или другой специальной обработки исходного значения; то есть, это разрешает преобразования, где у целевого типа есть более широкий диапазон чем исходный тип. У установки этого режима нет никакого опирания, разрешаются ли преобразования с потерями; этим управляют с `ALL_LOSSY` режим. Если только `ALL_NON_LOSSY` устанавливается, но нет `ALL_LOSSY`, тогда делая попытку преобразования, которое привело бы к потере данных (такой как `INT` к `TINYINT`, или `CHAR(25)` к `VARCHAR(20)`) заставляет ведомое устройство останавливаться с ошибкой.
`ALL_LOSSY,ALL_NON_LOSSY`	Когда этот режим устанавливается, все поддерживаемые преобразования типов разрешаются, являются ли они преобразованиями с потерями.
`ALL_SIGNED`	Обработайте продвинутые целочисленные типы как подписанные значения (поведение значения по умолчанию).
`ALL_UNSIGNED`	Обработайте продвинутые целочисленные типы как значения без знака.
`ALL_SIGNED,ALL_UNSIGNED`	Обработайте продвинутые целочисленные типы как подписано если возможный, иначе как без знака.
[пустой]	Когда `slave_type_conversions` не устанавливается, никакое продвижение атрибута или понижение в должности не разрешаются; это означает, что все столбцы в исходных и целевых таблицах должны иметь те же самые типы. Этот режим является значением по умолчанию.

Когда целочисленный тип продвигается, его signedness не сохраняется. По умолчанию ведомое устройство обрабатывает все такие значения как подписано. Начиная с MySQL 5.6.13, можно управлять этим использованием поведения ALL_SIGNED, ALL_UNSIGNED, или оба. (Bug#15831300) ALL_SIGNED говорит ведомому устройству обрабатывать все продвинутые целочисленные типы как подписано; ALL_UNSIGNED дает этому команду обрабатывать их как без знака. Определение обеих причин ведомое устройство, чтобы обработать значение как подписано если возможный, иначе обработать это как без знака; порядок, в котором они перечисляются, не является существенным. Ни один ALL_SIGNED ни ALL_UNSIGNED имеет любой эффект если по крайней мере один из ALL_LOSSY или ALL_NONLOSSY также не используется.

Изменение режима преобразования типов требует перезапуска ведомого устройства с новым slave_type_conversions установка.

Поддерживаемые преобразования. Поддерживаемые преобразования между различными но подобными типами данных показывают в следующем списке:

Между любым из целочисленных типов TINYINT, SMALLINT, MEDIUMINT, INT, и BIGINT.

Это включает преобразования между подписанными и версиями без знака этих типов.

Преобразования с потерями делаются, усекая исходное значение к максимуму (или минимум) разрешенными целевым столбцом. Для того, чтобы обеспечить преобразования нес потерями, идя от без знака до подписанных типов, целевой столбец должен быть достаточно большим, чтобы разместить диапазон значений в исходном столбце. Например, можно понизить в должности TINYINT UNSIGNED Y нес потерями к SMALLINT, но не к TINYINT.
Между любым из десятичных типов DECIMAL, FLOAT, DOUBLE, и NUMERIC.

FLOAT к DOUBLE преобразование нес потерями; DOUBLE к FLOAT может только быть обработан с потерями. Преобразование из DECIMAL(M,D) к DECIMAL(M',D') где M' => M и D' => D нес потерями; для любого случая, где M' < M, D' < D, или оба, только преобразование с потерями может быть сделано.

Для любого из десятичных типов, если значение, которое будет сохранено, не может быть, помещаются в целевой тип, значение округляется в меньшую сторону согласно округляющимся правилам, определенным для сервера в другом месте в документации. См. Раздел 12.19.4, "Округление Поведения", для информации о том, как это делается для десятичных типов.
Между любым из строковых типов CHAR, VARCHAR, и TEXT, включая преобразования между различными ширинами.

Преобразование a CHAR, VARCHAR, или TEXT к a CHAR, VARCHAR, или TEXT столбец тот же самый размер или больше никогда не с потерями. Преобразование с потерями обрабатывается, вставляя только первое N символы строки на ведомом устройстве, где N width целевого столбца.

Важный

Репликация между столбцами, используя различные наборы символов не поддерживается.
Между любым из двоичных типов данных BINARY, VARBINARY, и BLOB, включая преобразования между различными ширинами.

Преобразование a BINARY, VARBINARY, или BLOB к a BINARY, VARBINARY, или BLOB столбец тот же самый размер или больше никогда не с потерями. Преобразование с потерями обрабатывается, вставляя только первое N байты строки на ведомом устройстве, где N width целевого столбца.
Между любыми 2 BIT столбцы любых 2 размеров.

Вставляя значение от a BIT(M) столбец в a BIT(M') столбец, где M' > M, старшие значащие биты BIT(M') столбцы очищаются (обнуленные) и M биты BIT(M) значение устанавливается как младшие значащие биты BIT(M') столбец.

Вставляя значение из источника BIT(M) столбец в цель BIT(M') столбец, где M' < M, максимальное возможное значение для BIT(M') столбец присваивается; другими словами значение "все-набора" присваивается целевому столбцу.

Преобразования между типами не в предыдущем списке не разрешаются.

Преобразования типов репликации в MySQL 5.5.3 и ранее. До MySQL 5.5.3, с основанным на строке двоичным журналированием, Вы не могли тиражироваться между различным INT подтипы, такой как от TINYINT к BIGINT, потому что изменения к столбцам этих типов были представлены по-другому от друг друга в двоичном журнале при использовании основанного на строке журналирования. (Однако, Вы могли тиражироваться от BLOB к TEXT использование построчной репликации, потому что изменения к BLOB и TEXT столбцы были представлены, используя тот же самый формат в двоичном журнале.)

Поддерживаемые преобразования для продвижения атрибута при использовании построчной репликации до MySQL 5.5.3 показывают в следующей таблице:

От (Ведущего устройства)	К (Ведомому устройству)
`BINARY`	`CHAR`
`BLOB`	`TEXT`
`CHAR`	`BINARY`
`DECIMAL`	`NUMERIC`
`NUMERIC`	`DECIMAL`
`TEXT`	`BLOB`
`VARBINARY`	`VARCHAR`
`VARCHAR`	`VARBINARY`

Отметить

Во всех случаях размер или width столбца на ведомом устройстве должны быть равными или больше чем тот из столбца на ведущем устройстве. Например, Вы могли тиражироваться от a CHAR(10) столбец на ведущем устройстве к столбцу, который использовал BINARY(10) или BINARY(25) на ведомом устройстве, но Вы не могли тиражироваться от a CHAR(10) столбец на ведущем устройстве к BINARY(5) столбец на ведомом устройстве.

Любой уникальный индекс (включая первичные ключи) наличие префикса должен использовать префикс той же самой длины и на ведущем устройстве и на ведомом устройстве; в таких случаях отвергаются отличающиеся длины префикса. Возможно использовать групповое, индексируют, чья длина префикса отличается между ведущим устройством и ведомым устройством, но это может вызвать серьезные проблемы производительности, особенно когда префикс, используемый на ведущем устройстве, более длинен. Это - то, вследствие того, что 2 уникальных префикса данной длины больше, возможно, не уникальны в более коротком; например, каталог слов и дикая кошка имеют 5-символьные префиксы catal и catam, соответственно, но совместно используют тот же самый 4-символьный префикс (cata). Это может привести к запросам, которые используют такой, индексирует выполнение менее эффективно на ведомом устройстве, когда более короткий префикс используется в ведомом' определении того же самого, индексируют чем на ведущем устройстве.

Для DECIMAL и NUMERIC столбцы, и мантисса (M) и число десятичных чисел (D) должны быть тем же самым размером или больше на ведомом устройстве по сравнению с ведущим устройством. Например, репликация от a NUMERIC(5,4) к a DECIMAL(6,4) обработанный, но не от a NUMERIC(5,4) к a DECIMAL(5,3).

До MySQL 5.5.3 репликация MySQL не поддерживала продвижение атрибута любого из следующих типов данных к или от любого другого типа данных при использовании построчной репликации:

INT (включая TINYINT, SMALLINT, MEDIUMINT, BIGINT).

Продвижение между INT подтипы — например, от SMALLINT к BIGINT— также не поддерживался до MySQL 5.5.3.
SET или ENUM.
FLOAT или DOUBLE.
Все типы данных, касающиеся дат, времена, или оба: DATE, TIME, DATETIME, TIMESTAMP, и YEAR.