PLUK2011 Diagnosing and Fixing Mysql Replication
PLUK2011 Diagnosing and Fixing Mysql Replication
Introduction
-2-
About Me Sr Consultant at Percona since 2009 Worked with MySQL replication since 2004 Live in NW Washington About Percona Support, Consulting, Training, Development We create & maintain Percona-Server w/ XtraDB and XtraBackup Many other tools too: maatkit & aspersa percona-toolkit
www.percona.com
Table of Contents
-3-
Introduce the Problems Replication Architecture Review Masters, Slaves, and the many files they keep Different ways things break How to diagnose the problems Knowing when to skip it, when and how to fix it, and when to just rebuild it. Questions (if we have time)
www.percona.com
Replication is Ubiquitous
-4-
Load distribution Redundancy (local or geographic) Master-Master fail-over Taking backups from slave Archiving & Data Warehousing Many other things too
www.percona.com
-5-
www.percona.com
-6-
Explicit TEMP TABLE causes replication failure if mysqld restarted Date arithmetic in Stored Procedure breaks replication replicate-ignore-db behaves differently with different binlog formats INSERT..ON DUP KEY UPDATE unsafe if more than one unique key SHOW SLAVE STATUS gives wrong output with master-master and using SET uservars
http://bit.ly/MysqlRepBugs
www.percona.com
-7-
Duplicate key errors Temp table does not exist after slave restart Binary and relay log corruption Slave reads from wrong position after crash And more...
www.percona.com
But first
We need to know a little about how MySQL replication works
-8-
Master & Slave threads Binary & Relay log files Status files (or status tables in 5.6)
If you want to know more, see Lars Thalmann's presentations http://bit.ly/LarsRepTalk http://bit.ly/LarsRepTalk1
www.percona.com
A Brief Review
Write to Keeps list at
-9-
Master Host
master-bin.xxx master-bin.index
Slave Host
relay.info relay-bin.xxx
http://bit.ly/5-5-slave-log-status
www.percona.com
-10-
You sometimes need to edit these files manually (but only in dire situations)
www.percona.com
-11-
www.percona.com
-12-
local read position Slave:$ cat relay-log.info of sql_thd ./relay-bin.000002 Relay_Log_File 1392 Relay_Log_Pos master-bin.000001 Relay_Master_Log_File 1818 Exec_Master_Log_Pos remote read position of sql_thd
These positions correspond to the end_log_pos of the last statement executed by sql_thread
www.percona.com
Running Example
~/sandboxes$ make_repl_sandbox --circular 2 5.1.55 Percona-Server-5.1.55-rel12.6-200-Linux-x86_64 Node1 = Active master | Node2 = Passive Master node1 > create table foo ( id int not null auto_increment primary key, v varchar(255) not null default '', unique (v)) engine=innodb; Query OK, 0 rows affected (0.01 sec) node1 > insert into foo (v) values ('a'), ('b'); Query OK, 2 rows affected (0.01 sec) Records: 2 Duplicates: 0 Warnings: 0
www.percona.com
mysqlbinlog on masters
# at 1610 #110318 14:20:12 server id 101 end_log_pos 1683 Query thread_id=8 exec_time=0 error_code=0 SET TIMESTAMP=1300483212/*!*/; BEGIN/*!*/; # at 1683 #110318 14:20:12 server id 101 end_log_pos 1791 Query thread_id=8 exec_time=0 error_code=0 SET TIMESTAMP=1300483212/*!*/; INSERT INTO `foo` VALUES (1,'a'),(2,'b')/*!*/; # at 1791 #110318 14:20:12 server id 101 Xid = 32 COMMIT/*!*/; end_log_pos 1818
www.percona.com
www.percona.com
www.percona.com
www.percona.com
-19-
www.percona.com
My Approach
When replication stops...
-20-
Why did it stop? This usually tells you how to fix it Generally does not take much time Where did it break? Determine extent of corruption / data loss Were statements skipped or run twice? What is the business impact? Don't over-analyze. Estimate is probably OK at this step.
www.percona.com
My Approach
Now that you know why it stopped...
-21-
Choose your restore method Do you prioritize site availability or data integrity? Validate slave consistency If possible, before allowing traffic if necessary, use tools to resync the slave Have a plan B Sometimes you just need to rebuild
www.percona.com
Learned from experience Based on common principles Similar even for different organizations
www.percona.com
-23-
Writes on the slave File corruption in binary or relay-log Documented limitation in MySQL Un/known Bugs?
Hardware fails mysqld crash Kernel panic / OOM killer kill -9 `pidof mysqld` Host recently restarted and rolled back status file
www.percona.com
-24-
Crash caused replication to stop skip-slave-start innodb_overwrite_relay _log_info (only in Percona-Server) 5.6-labs features http://bit.ly/crash-safe-replication
www.percona.com
Common Situations
Documented limitations & bugs Writes on the slave File Corruption Hardware Failures
www.percona.com
Documented Limitations
www.percona.com
Documented limitations
-27-
Statement-Based Replication (SBR) has many limitations Documentation: http://bit.ly/5-5-rep-limits 33 subsections Still the default format, even in 5.5 Row-Based Replication (RBR) avoids most limitations But not all: http://bit.ly/5-5-rbr-limits All tables require a PRIMARY KEY Can be more difficult to do online alter table than SBR
www.percona.com
Documented limitations
-28-
Get to know the limitations & open bugs Some are documented as bug reports Avoid them like the plague Watch the patch notes like a hawk (even if you don't upgrade) Change your application as necessary
www.percona.com
-29-
Non-Deterministic functions or statements UUID, NOW, CURRENT_USER, FOUND_ROWS UPDATE|DELETE with LIMIT but no ORDER BY TEMPORARY and MEMORY tables SET TX_ISOLATION = READ_COMMITTED Routines / Triggers with logical expressions Dynamic SQL And lots more ...
www.percona.com
Can't read SQL in binary log Different DDL on master / slave breaks RBR (*) Slave calls fsync() for every row, not every transaction
Mixing InnoDB and MyISAM in one transaction ... It's just not a good idea! Order of binlog events changed multiple times in 5.1
(*) Percona is working to enable slaves with different table definitions to replay RBR events that would normally fail.
www.percona.com
www.percona.com
-32-
node2 > insert into foo (v) values ('bad insert'); node2 > select * from foo; | 1 | a | | 2 | b | | 3 | bad insert | node1 > insert into foo (v) values ('c'); node2 > show slave status\G Last_Errno: 1062 Last_Error: Error 'Duplicate entry '3' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'insert into foo (v) values ('c')'
www.percona.com
-33-
www.percona.com
-34-
DELETE record from slave; optionally, insert to master may preserve data integrity insert to master allows you to keep the record more time-consuming than SKIP_COUNTER foreign keys and triggers make this very complicated!
www.percona.com
-35-
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; easiest method data inconsistency may propagate to other tables, eg. if you use INSERT..SELECT or triggers must sync later with pt-table-sync
www.percona.com
-36-
auto_increment_increment & _offset would have prevented failure in this example safe to do even if you never write to slave master = even, slave = odd makes it trivial to identify bad writes - `id` will be odd
www.percona.com
-37-
node2 > insert into foo (v) values ('bad insert'); node2 > SHOW SLAVE STATUS\G Error 'Duplicate entry '3' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'insert into foo (v) values ('c')'
Note: I used SLAVE STOP; on both hosts to simulate simultaneous writes
www.percona.com
-38-
Fixing master-master is same principle as master-slave... But you might accidentally corrupt your primary master! So be extra careful...
For example: DELETE record from secondary; optionally, insert to primary Use SET SESSION SQL_LOG_BIN = 0 for DELETE But allow INSERT to replicate normally
www.percona.com
-39-
SET SQL_SLAVE_SKIP_COUNTER = 1 On both masters Then sync with pt-table-sync auto_increment_increment & _offset A must have if you use AUTO_INC + master-master replication + fail-over
www.percona.com
www.percona.com
-41-
File Corruption
www.percona.com
File Corruption
Slave may stop if any of these files become corrupt Binary log | Relay log | Table data | Index data Examples of SHOW SLAVE STATUS
Last_IO_Error: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log Last_SQL_Errno: 1594 Last_SQL_Error: Relay log read failure: Could not parse relay log event entry.
www.percona.com
Verify it with mysqlbinlog [--verbose --base64] Find extent of corruption CHANGE MASTER TO Master_Log_Pos = <good_pos> Analyze bad section of log. Identify all affected tables. Use pt-table-sync when replication catches up. Resolve underlying (hardware) cause of the corruption!
www.percona.com
Verify it with mysqlbinlog <relay-log-file> Check master binlog for corruption. If it is, see previous slide. Re-fetch the corrupted relay log CHANGE MASTER TO Master_Log_Pos = <Exec_master_log_pos>; Very rare If this occurs frequently, check for network problems.
www.percona.com
If a Table is Corrupt...
Stop replication and stop all traffic to that server Mount the file system read-only Check mysql error log - it may contain more info Even after fixing the corruption, pt-table-sync Sometimes, only option is restore from a backup
www.percona.com
Hardware Failures
A SAN is just a bigger SPoF -unknown
www.percona.com
HW Failure #1
Unplanned master restart all slaves stop with error: 'Client requested master to start replication from impossible position' Process: Compare each SLAVE STATUS to master binlog Realize that Exec_Master_Log_Pos different on each slave, and greater than master's log file size! Panic for a minute...
www.percona.com
HW Failure #1
Possible solutions: Promote slave that read the most Isolate extra events from slave binlog, replay on master Force slaves to resume from next binlog, then pt-table-sync to remove extra events Prevent with: RAID BBU + HDD cache disabled innodb_flush_log_at_trx_commit = 1 sync_binlog = 1
www.percona.com
HW Failure #2
Replaced a failed disk in a replica. After restart, replication fails with duplicate key error. Process: Check error log... there's no slave stop coordinates! Realize file system in read-only mode before shut down Was master.info rolled back by file system journal?
www.percona.com
HW Failure #2
Possible solutions: Guess where slave stopped, then CHANGE MASTER But what if data files also rolled back? SQL_SLAVE_SKIP_COUNTER + prayers + pt-table-sync Rebuild the slave Prevent with: Percona Server + innodb_overwrite_relay_log_info
www.percona.com
War Stories
-51-
Slave generates different auto_inc values for INSERT inside an ON_INSERT TRIGGER. This goes unnoticed for months, then starts causing problems. During MMM migration, a few uncommitted transactions get left behind and cause duplicate key errors on both nodes Major hardware failure in a geo-distributed three-node replication ring. Each host is written to by local processes. There are some tables only written on single host, but also some shared tables that all write to. How do you determine which of remaining two masters is good?
www.percona.com
Gold Sponsor
Silver Sponsors
www.percona.com
Media Sponsors
www.percona.com
[email protected] devananda.vdv@gmail
www.percona.com/live