Changes between Version 11 and Version 12 of PS1_IPP_Czarlog_20141208

Timestamp:

Dec 9, 2014, 8:17:20 AM (12 years ago)

Author:

eugene

Comment:

--

PS1_IPP_Czarlog_20141208

@@ -28 +28 @@
  * 07:45 EAM : processing has been limping along, with a number of the 'table full' errors.  there is enough room on the disk after Serge purged the binary logs, so that is not the cause.  the tables are big, but not approaching the InnoDB 64 TB max values.  The load on the machine (ippdb00) is modest (3-4).  I am guessing that a restart of mysql might clear out something which is cached?
  * 08:10 EAM : more research has revealed the likely cause: the number of concurrent transactions was too large (the full disk probably also triggered this).  I turned down the number of nodes doing cleanup and this seems to be making things better (lower error rate).  the following mysql bug report is relevant (and points out that 5.5.xx has bumped the transaction limit): http://bugs.mysql.com/bug.php?id=26590
+ * 08:15 EAM : addendum: this is probably not as critical, but we may want to bump the ibdata file.  this is from the mysql manual (http://dev.mysql.com/doc/refman/5.0/en/innodb-data-log-reconfiguration.html)
 
+{{{
+For example, this tablespace has just one auto-extending data file ibdata1:
+
+innodb_data_home_dir =
+innodb_data_file_path = /ibdata/ibdata1:10M:autoextend
+Suppose that this data file, over time, has grown to 988MB. Here is the configuration line after modifying the original data file to not be auto-extending and adding another auto-extending data file:
+
+innodb_data_home_dir =
+innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
+When you add a new file to the tablespace configuration, make sure that it does not exist. InnoDB will create and initialize the file when you restart the server.
+}}}
 === Wednesday : YYYY.MM.DD ===