I’ll keep this short. Let’s say you run “mysql> show slave status\G” and you see the following error:
Last_Error: Error 'Unknown or incorrect time zone: 'Etc/UTC'' on query. Default database: 'db_name'. Query: 'INSERT INTO table SET column = CONVERT_TZ('2009-01-24', '-8:00', '+00:00')'
It’s a simple fix. Exit out of MySQL and run the following command – this works on Redhat, I’ve not tried it on other flavors.
shell> mysql_tzinfo_to_sql /usr/share/zoneinfo|mysql -u root -p
Log back into MySQL and run the following.
mysql> stop slave;
mysql> start slave;
mysql> show slave status\G;
The error should be gone and the slave should be catching up to the master now. Problem solved.
Let’s begin by assuming you have a server that runs MySQL and lots and lots of traffic flows through it everyday, let’s say… something like 50% of the size of the partition that the mysql binary logs are written to is on, then we will assume the binary log is turned on. Then we assume that expire_logs_days is not set.
What happens? Nagios/etc alerts that the partition is reaching a usage threshold because – low and behold the binary logs are filling up the partition. Tuning this variable is also important. It may need to be set to as low as 1 day, in which case I would say we need a bigger partition for binary logs, but setting it so low can cause replication problems if the slave(s) gets behind more than 1 day – god help us if it does – then those binary logs that the slave is reading are no longer available, and rebuilding replication will be next on the task list. (or using maatkit)
While I’m at it here are some good ones for relieving tension. By no means is this a full list but some things on the top of my head at the moment.
expire_logs_days = x
myisam_recover
skip_bdb
sql_mode = NO_AUTO_CREATE_USER
max_binlog_size = x
long_query_time = x
log_slow_queries
log_warnings
transaction-isolation=REPEATABLE-READ (or SERIALIZABLE)
Had a customer issue come through right before I left for the day. Hadn’t seen this happen before and google was not too helpful.
Problem: We had the tmp-dir set as /var/tmp which was on it’s own partition of 5GB. This is a relatively small database of about 15GB. Customer has some replication slaves setup and was running a LOAD DATA INFILE on the master. File was about 12GB, so the slave creates a SQL-DATA-1024-512.data file in the tmp directory to buffer that INFILE command coming from the master. Well, eventually that filled up the /var/tmp partition.
Solution: stop the server, change the tmp-dir=/bigger-partition, move the file to the new tmp location, restart cluster, all good.
Prevention: Make sure your tmp-dir setting is on a large enough partition to hold your temporary files, and make sure if you’re going to load a data file on the master that’s bigger than your slave tmp-dir that it will halt the Slave_SQL_thread once the partition fills up and you’ll have a headache on your hands.
Current Books in Review
