gistfile1.txt

=================================
What I've learned so far...
=================================
[raymond] says that daily optimize is probably too much. Instead, only run when your data is 'churned'. 
10:33 < deafferret> [raymond]: want to give me a clue about how to know if my data is churned?
10:34 < [raymond]> deafferret: SHOW GLOBAL STATUS LIKE 'Com_%'; -- look through that list, you'll find some interesting data points.



=================================
The question / problem
=================================
Hypothesis: When I run mysqlcheck --optimize on ServerA, that runs 'OPTIMIZE TABLE
 X' on ServerA. ServerB (a replication slave) reads that statement from the
 transaction log, and also runs 'OPTIMIZE TABLE X'. Therefore, it is redundant to
 run mysqlcheck --optimize on ServerB. Plausible?


I'm running this in cron every morning on both ServerA and ServerB:
mysqlcheck --user=root --password=SuperSecret --auto-repair --check \
   --optimize --all-databases

Is that redundant? Bad practice?


When ServerA bounces, ServerB replication stops, like so:


mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: omares-intranet3
                Master_User: repl
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000005
        Read_Master_Log_Pos: 5124085
             Relay_Log_File: mysql-relay-bin.000009
              Relay_Log_Pos: 235
      Relay_Master_Log_File: mysql-bin.000004
           Slave_IO_Running: Yes
          Slave_SQL_Running: No
            Replicate_Do_DB:
        Replicate_Ignore_DB: information%,mysql%,oma,apect%,webcal%,crm%,test%,information%,mysql%,oma,apect%,webcal%,crm%,test%
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table: oma_repl.%,rt3.%,wikidb.%,oma_repl.%,rt3.%,wikidb.%
Replicate_Wild_Ignore_Table:
                 Last_Errno: 1053
                 Last_Error: Query partially completed on the master (error on 
master: 1053) and was aborted. There is a chance that your master is inconsistent
 at this point. If you are sure that your master is ok, run this query manually on
 the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
 START SLAVE; . Query: 'OPTIMIZE TABLE `Attachments`'
               Skip_Counter: 0
        Exec_Master_Log_Pos: 433658362
            Relay_Log_Space: 5124596
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)