whither your rollback plan?mysql 5.6 upgrades are in full swing these days and knowing how to safely upgrade from mysql 5.5 to 5.6 is important. when upgrading a replication environment, it’s important that you can build a migration plan that safely allows for your upgrade with minimal risk — rollback is often a very important component to this.
for many people this means upgrading slaves first and then the master. the strategy of an older master replicating to a newer slave is well known and has been supported in mysql replication for a very long time. to be specific: you can have a mysql 5.6 slave of a 5.5 master and this should work fine until you upgrade your master and/or promote one of the slaves to be the master.
however, there are those of us who like to live on the edge and do unsupported things. suppose that when you cut over to that mysql 5.6 master your application completely breaks. what would your rollback plan be? in such a case, leaving a 5.5 slave of the new 5.6 master (or perhaps a dual-master setup with 5.5 and 5.6) would be useful to allow you to rollback to but still have the data written on the 5.6 master.
what might break?with statement-based replication (sbr), you are generally ok with this type of setup, provided you aren’t doing any mysql 5.6 syntax-specific things until you don’t have any more 5.5 slaves. however, with row-based replication (rbr), things are a bit trickier, particularly when column formats change.
now, one nice new feature of mysql 5.6 is the improvement of thestorage requirements fordatetime fields as well as the addition of fractional second support for time, datetime, and timestamp. this is great, but unfortunately this is a new column format that 5.5 clearly would not understand. does this put our 5.6 to 5.5 replication in jeopardy? the answer is, if we’re careful, no.
quite simply, mysql 5.6 supports both old and new types and mysql_upgrade does not make such a conversion on existing tables. only new tables or rebuilt tables in 5.6 will use the new format. any tables from 5.5 with a simple mysql_upgrade to 5.6 will still be using the old types. for more information on how to find columns in 5.6 that are using the old format, seeike walker’s excellent blog post on the topic. (thanks ike!)
an imperfect testto test this out, i created a simple experiment. i have a master and slave using rbr, both on 5.5, and i setuppt-heartbeatto update the master. i realized that pt-heartbeat actually uses a varchar for the timestamp field — i suspect this makes multiple database support easier. however, since pt-heartbeat’s update uses a now() to populate that field, i can convert it to a datetime:
[root@master ~]# pt-heartbeat --update --database percona --create-tablecreate table `heartbeat` (`ts` varchar(26) not null,`server_id` int(10) unsigned not null,`file` varchar(255) default null,`position` bigint(20) unsigned default null,`relay_master_log_file` varchar(255) default null,`exec_master_log_pos` bigint(20) unsigned default null,primary key (`server_id`)) engine=innodb default charset=latin1master mysql> alter table heartbeat drop column ts, add column ts datetime;slave mysql> select * from heartbeat/g *************************** 1. row *************************** server_id: 1file: master-bin.000002position: 5107583 relay_master_log_file: null exec_master_log_pos: nullts: 2014-05-02 17:03:59 1 row in set (0.00 sec) create table `heartbeat` ( `server_id` int(10) unsigned not null, `file` varchar(255) default null, `position` bigint(20) unsigned default null, `relay_master_log_file` varchar(255) default null, `exec_master_log_pos` bigint(20) unsigned default null, `ts` datetime default null, primary key (`server_id`) ) engine=innodb default charset=latin1
[root@master~]# pt-heartbeat --update --database percona --create-table
createtable`heartbeat`(
`ts`varchar(26)notnull,
`server_id`int(10)unsignednotnull,
`file`varchar(255)defaultnull,
`position`bigint(20)unsigneddefaultnull,
`relay_master_log_file`varchar(255)defaultnull,
`exec_master_log_pos`bigint(20)unsigneddefaultnull,
primarykey(`server_id`)
)engine=innodbdefaultcharset=latin1
mastermysql>altertableheartbeatdropcolumnts,addcolumntsdatetime;
slavemysql>select*fromheartbeat/g
***************************1.row***************************
server_id:1
file:master-bin.000002
position:5107583
relay_master_log_file:null
exec_master_log_pos:null
ts:2014-05-0217:03:59
1rowinset(0.00sec)
createtable`heartbeat`(
`server_id`int(10)unsignednotnull,
`file`varchar(255)defaultnull,
`position`bigint(20)unsigneddefaultnull,
`relay_master_log_file`varchar(255)defaultnull,
`exec_master_log_pos`bigint(20)unsigneddefaultnull,
`ts`datetimedefaultnull,
primarykey(`server_id`)
)engine=innodbdefaultcharset=latin1
so my heartbeat table now has a 5.5 datetime, pt-heartbeat is working properly, and the heartbeat is replicating to the slave. now i will upgrade my master to mysql 5.6:
[root@master ~]# rpm -e percona-server-devel-55-5.5.36-rel34.2.el6.x86_64 percona-server-shared-55-5.5.36-rel34.2.el6.x86_64 percona-server-client-55-5.5.36-rel34.2.el6.x86_64 percona-server-server-55-5.5.36-rel34.2.el6.x86_64 --nodeps[root@master ~]# yum install percona-server-server-56.x86_64==============================================================================================================package archversion repositorysize==============================================================================================================installing:percona-server-server-56x86_645.6.16-rel64.2.el6percona 19 minstalling for dependencies:percona-server-client-56x86_645.6.16-rel64.2.el6percona6.8 mpercona-server-shared-56x86_645.6.16-rel64.2.el6percona712 ktransaction summary==============================================================================================================install 3 package(s)...[root@master ~]# service mysql startstarting mysql (percona server)....... success![root@master ~]# mysqlwelcome to the mysql monitor.commands end with ; or /g.your mysql connection id is 1server version: 5.6.16-64.2-56-log percona server (gpl), release 64.2, revision 569[root@master ~]# mysql_upgradelooking for 'mysql' as: mysqllooking for 'mysqlcheck' as: mysqlcheckrunning 'mysqlcheck with default connection argumentsrunning 'mysqlcheck with default connection argumentsmysql.columns_priv okmysql.db okmysql.eventokmysql.func okmysql.general_logokmysql.help_categoryokmysql.help_keyword okmysql.help_relationokmysql.help_topic okmysql.host okmysql.ndb_binlog_index okmysql.plugin okmysql.proc okmysql.procs_priv okmysql.proxies_priv okmysql.serversokmysql.slow_log okmysql.tables_privokmysql.time_zoneokmysql.time_zone_leap_secondokmysql.time_zone_name okmysql.time_zone_transition okmysql.time_zone_transition_typeokmysql.user okrunning 'mysql_fix_privilege_tables'...running 'mysqlcheck with default connection argumentsrunning 'mysqlcheck with default connection argumentspercona.heartbeatokok
[root@master~]# rpm -e percona-server-devel-55-5.5.36-rel34.2.el6.x86_64 percona-server-shared-55-5.5.36-rel34.2.el6.x86_64 percona-server-client-55-5.5.36-rel34.2.el6.x86_64 percona-server-server-55-5.5.36-rel34.2.el6.x86_64 --nodeps
[root@master~]# yum install percona-server-server-56.x86_64
==============================================================================================================
package arch version repository size
==============================================================================================================
installing:percona-server-server-56 x86_64 5.6.16-rel64.2.el6 percona 19m
installingfordependencies:
percona-server-client-56 x86_64 5.6.16-rel64.2.el6 percona 6.8m
percona-server-shared-56 x86_64 5.6.16-rel64.2.el6 percona 712k
transactionsummary
==============================================================================================================
install 3package(s)
...[root@master~]# service mysql start
startingmysql(perconaserver).......success!
[root@master~]# mysql
welcometothemysqlmonitor. commandsendwith;or/g.
yourmysqlconnectionidis1
serverversion:5.6.16-64.2-56-logperconaserver(gpl),release64.2,revision569
[root@master~]# mysql_upgrade
lookingfor'mysql'as:mysql
lookingfor'mysqlcheck'as:mysqlcheck
running'mysqlcheckwithdefaultconnectionarguments
running'mysqlcheckwithdefaultconnectionarguments
mysql.columns_priv ok
mysql.db ok
mysql.event ok
mysql.func ok
mysql.general_log ok
mysql.help_category ok
mysql.help_keyword ok
mysql.help_relation ok
mysql.help_topic ok
mysql.host ok
mysql.ndb_binlog_index ok
mysql.plugin ok
mysql.proc ok
mysql.procs_priv ok
mysql.proxies_priv ok
mysql.servers ok
mysql.slow_log ok
mysql.tables_priv ok
mysql.time_zone ok
mysql.time_zone_leap_second ok
mysql.time_zone_name ok
mysql.time_zone_transition ok
mysql.time_zone_transition_type ok
mysql.user ok
running'mysql_fix_privilege_tables'...
running'mysqlcheckwithdefaultconnectionarguments
running'mysqlcheckwithdefaultconnectionarguments
percona.heartbeat ok
ok
i can now verify that ike’s information_schema queries correctly detect the ‘heartbeat.ts’ column as the old format:
master mysql> select t.table_schema,t.engine,t.table_name,c.column_name,c.column_typefrom information_schema.tables tinner join information_schema.columns c on c.table_schema = t.table_schema and c.table_name = t.table_nameleft outer join information_schema.innodb_sys_tables ist on ist.name = concat(t.table_schema,'/',t.table_name)left outer join information_schema.innodb_sys_columns isc on isc.table_id = ist.table_id and isc.name = c.column_namewhere c.column_type in ('time','timestamp','datetime')and t.table_schema not in ('mysql','information_schema','performance_schema')and t.table_type = 'base table'and (t.engine != 'innodb' or (t.engine = 'innodb' and isc.mtype = 6))order by t.table_schema,t.table_name,c.column_name; +--------------+--------+------------+-------------+-------------+ | table_schema | engine | table_name | column_name | column_type | +--------------+--------+------------+-------------+-------------+ | percona| innodb | heartbeat| ts| datetime| +--------------+--------+------------+-------------+-------------+ 1 row in set (0.04 sec)
mastermysql>selectt.table_schema,t.engine,t.table_name,c.column_name,c.column_type
frominformation_schema.tablest
innerjoininformation_schema.columnsconc.table_schema=t.table_schemaandc.table_name=t.table_name
leftouterjoininformation_schema.innodb_sys_tablesistonist.name=concat(t.table_schema,'/',t.table_name)
leftouterjoininformation_schema.innodb_sys_columnsisconisc.table_id=ist.table_idandisc.name=c.column_name
wherec.column_typein('time','timestamp','datetime')
andt.table_schemanotin('mysql','information_schema','performance_schema')
andt.table_type='base table'
and(t.engine!='innodb'or(t.engine='innodb'andisc.mtype=6))
orderbyt.table_schema,t.table_name,c.column_name;
+--------------+--------+------------+-------------+-------------+
|table_schema|engine|table_name|column_name|column_type|
+--------------+--------+------------+-------------+-------------+
|percona |innodb|heartbeat |ts |datetime |
+--------------+--------+------------+-------------+-------------+
1rowinset(0.04sec)
to make replication work from mysql 5.6 to 5.5, i also had to add a few backwards compatibility options on the master:
log_bin_use_v1_row_events = onbinlog_checksum = none
log_bin_use_v1_row_events=on
binlog_checksum=none
once i fixed that up, i can verify my slave is still working after this and receiving heartbeats. clearly the new formats are not a show-stopper for backwards replication compatibility.
slave mysql> show slave status/g*************************** 1. row *************************** slave_io_state: waiting for master to send eventmaster_host: 192.168.70.2master_user: replmaster_port: 3306connect_retry: 60master_log_file: master-bin.000005read_master_log_pos: 120 relay_log_file: slave-relay-bin.000002relay_log_pos: 267relay_master_log_file: master-bin.000005 slave_io_running: yesslave_sql_running: yesmaster mysql> select * from heartbeat;+-----------+-------------------+----------+-----------------------+---------------------+---------------------+| server_id | file| position | relay_master_log_file | exec_master_log_pos | ts|+-----------+-------------------+----------+-----------------------+---------------------+---------------------+| 1 | master-bin.000002 |5115935 | null|null | 2014-05-02 17:04:23 |+-----------+-------------------+----------+-----------------------+---------------------+---------------------+1 row in set (0.01 sec)slave mysql> select * from heartbeat;+-----------+-------------------+----------+-----------------------+---------------------+---------------------+| server_id | file| position | relay_master_log_file | exec_master_log_pos | ts|+-----------+-------------------+----------+-----------------------+---------------------+---------------------+| 1 | master-bin.000002 |5115935 | null|null | 2014-05-02 17:04:23 |+-----------+-------------------+----------+-----------------------+---------------------+---------------------+1 row in set (0.00 sec)
slavemysql>showslavestatus/g
***************************1.row***************************
slave_io_state:waitingformastertosendevent
master_host:192.168.70.2
master_user:repl
master_port:3306
connect_retry:60
master_log_file:master-bin.000005
read_master_log_pos:120
relay_log_file:slave-relay-bin.000002
relay_log_pos:267
relay_master_log_file:master-bin.000005
slave_io_running:yes
slave_sql_running:yes
mastermysql>select*fromheartbeat;
+-----------+-------------------+----------+-----------------------+---------------------+---------------------+
|server_id|file |position|relay_master_log_file|exec_master_log_pos|ts |
+-----------+-------------------+----------+-----------------------+---------------------+---------------------+
| 1|master-bin.000002| 5115935|null | null|2014-05-0217:04:23|
+-----------+-------------------+----------+-----------------------+---------------------+---------------------+
1rowinset(0.01sec)
slavemysql>select*fromheartbeat;
+-----------+-------------------+----------+-----------------------+---------------------+---------------------+
|server_id|file |position|relay_master_log_file|exec_master_log_pos|ts |
+-----------+-------------------+----------+-----------------------+---------------------+---------------------+
| 1|master-bin.000002| 5115935|null | null|2014-05-0217:04:23|
+-----------+-------------------+----------+-----------------------+---------------------+---------------------+
1rowinset(0.00sec)
but, if i’m not careful on mysql 5.6, and rebuild the table, the new format does clearly bite me:
master mysql> set sql_log_bin=0;query ok, 0 rows affected (0.00 sec)master mysql> alter table percona.heartbeat force;query ok, 1 row affected, 1 warning (0.18 sec)records: 1duplicates: 0warnings: 1master mysql> show warnings;+-------+------+-------------------------------------------------------------------------------------+| level | code | message |+-------+------+-------------------------------------------------------------------------------------+| note| 1880 | time/timestamp/datetime columns of old format have been upgraded to the new format. |+-------+------+-------------------------------------------------------------------------------------+1 row in set (0.00 sec)slave mysql> show slave status/g*************************** 1. row ***************************... slave_io_running: yesslave_sql_running: no... last_errno: 1677 last_error: column 5 of table 'percona.heartbeat' cannot be converted from type '' to type 'datetime'... last_sql_errno: 1677 last_sql_error: column 5 of table 'percona.heartbeat' cannot be converted from type '' to type 'datetime'replicate_ignore_server_ids: master_server_id: 11 row in set (0.00 sec)
mastermysql>setsql_log_bin=0;
queryok,0rowsaffected(0.00sec)
mastermysql>altertablepercona.heartbeatforce;
queryok,1rowaffected,1warning(0.18sec)
records:1 duplicates:0 warnings:1
mastermysql>showwarnings;
+-------+------+-------------------------------------------------------------------------------------+
|level|code|message |
+-------+------+-------------------------------------------------------------------------------------+
|note |1880|time/timestamp/datetimecolumnsofoldformathavebeenupgradedtothenewformat.|
+-------+------+-------------------------------------------------------------------------------------+
1rowinset(0.00sec)
slavemysql>showslavestatus/g
***************************1.row***************************
... slave_io_running:yes
slave_sql_running:no
... last_errno:1677
last_error:column5oftable'percona.heartbeat'cannotbeconvertedfromtype''totype'datetime'
... last_sql_errno:1677
last_sql_error:column5oftable'percona.heartbeat'cannotbeconvertedfromtype''totype'datetime'
replicate_ignore_server_ids:
master_server_id:1
1rowinset(0.00sec)
tl;drwhat does all this teach us?
while the mysql version is important, for rbr what matters most is the actual current format for each column. your master and slave(s) must have the same column formats for rbr to work right.
so, the new temporal formats do not necessarily break rbr replication back to 5.5, provided:
all base mysql 5.6 enhancements to replication are disabled (binlog checksums and the rbr v2 format)tables with temporal formats are preserved in their 5.5 formats until all 5.5 nodes are retired.you can avoid creating any new tables on the mysql 5.6 master with temporal formatshowever, i want to make it clear that mysql 5.6 to 5.5 replication is technically unsupported. i have not exhausted all possibilities for problems with 5.6 to 5.5 rbr replication, just this specific one. if you choose to make an upgrade strategy that relies on backwards replication in this way, be prepared for it to not work and test it thoroughly in advance. the purpose of this post is to simply point out that data type formats, in and of themselves, do not necessarily break rbr backwards compatibility.