tag:help-archives.hannonhill.com,2010-02-09:/discussions/installation/56-database-error-on-upgrade-to-673Cascade CMS: Discussion 2014-03-25T20:55:34Ztag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-28T15:02:48Z2010-10-28T15:02:48ZDatabase error on upgrade to 6.7.3<div><p>Hi Jim,</p>
<p>Can you please attach the entire <strong>cascade.log</strong> file (from Oct. 27) here?</p>
<p>Thanks!</p></div>Timtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-28T16:10:33Z2010-10-28T16:10:33ZDatabase error on upgrade to 6.7.3<div><p>Tim,</p>
<p>Attached is a zip file with the log from Oct. 27. I compressed it because it was well over the 10MB in size limit (108MB)</p>
<p>Thanks,</p>
<p>Jim</p></div>jkreuzigtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-28T18:51:26Z2010-10-28T18:51:26ZDatabase error on upgrade to 6.7.3<div><p>Thanks Jim! I've been looking over some of the errors but I may need a little more time for investigating. I'll let you know as soon as I have more information for you.</p>
<p>In the meantime, can you tell me:</p>
<ul>
<li>Which version of MySQL is the test instance using?</li>
<li>Which version of MySQL is the production instance using?</li>
<li>If test and production point to separate databases (same MySQL version or not), are the MySQL configuration files the same? (my.cnf/my.ini)</li>
</ul>
<p>Thanks</p></div>Timtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-28T22:36:25Z2010-10-28T22:36:25ZDatabase error on upgrade to 6.7.3<div><p>Tim,</p>
<ul>
<li>Which version of MySQL is the test instance using? - <em>We are running mysql-5.1.33-solaris10-sparc-64bit</em></li>
<li>Which version of MySQL is the production instance using? - <em>Same as test **(mysql-5.1.33-solaris10-sparc-64bit)</em></li>
<li>If test and production point to separate databases (same MySQL version or not), are the MySQL configuration files the same? (my.cnf/my.ini) - <em>I thought this might have been the problem. The my.cnf files were not the same, but I shut everything down on the test server and changed the my.cnf to match the production server. A restart of everything produces the same results as mentioned above</em></li>
</ul>
<p>I've attached mysql config file. It's remained largely unchanged for the last year and a half. The only thing I changed is when I allocated more memory to the innodb_buffer_pool_size variable. It was set to 2GB when we were running a 32bit version of mysql and I increased it to 6GB when we moved to the 64bit version. That was about a year ago.</p>
<p>Jim</p></div>jkreuzigtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-29T13:52:02Z2010-10-29T13:52:02ZDatabase error on upgrade to 6.7.3<div><p>Hi Jim,</p>
<p>Thanks for that information. We use the READ-COMMITTED isolation level for better reliability in our Quartz scheduling layer. This change was introduced in 6.7.3.</p>
<p>Unfortunately, this isolation level is incompatible with statement-level binary logging in MySQL . After a bit of research, it doesn't seem like MySQL is going to address this underlying issue. As of now, it appears that the only option will be to either switch to row-level binary logging or disable it entirely.</p>
<p>Please let me know if you have further questions.</p>
<p>Thanks</p></div>Timtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-29T22:45:16Z2010-10-29T22:45:16ZDatabase error on upgrade to 6.7.3<div><p>Tim,</p>
<p>I've gone ahead and changed the my.cnf file to add the following:</p>
<pre><code>transaction_isolation = READ-COMMITTED
binlog_format=ROW</code></pre>
<p>It seems to work. The only real side affect now is that my binary log files grow bigger quicker.<br />
</p>
<p>I don't know how many of your customers use MySQL, but the default setting on the "transaction_isolation" setting varies with which version of MySQL one is using. See the following:</p>
<pre><code>http://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html#sysvar_binlog_format</code></pre>
<p>It describes how they changed the default value from version to version. This is probably going to be something that affects more than just us here at UCI.</p>
<p>Thanks again for the prompt feedback.</p>
<p>Jim</p></div>jkreuzigtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-10-29T23:14:05Z2010-10-29T23:14:05ZDatabase error on upgrade to 6.7.3<div><p>You do not want to set an isolation level for the entire MySQL instance. Our application specifies this for individual transactions on it's own.</p></div>Bradley Wagnertag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-11-01T17:47:38Z2010-11-01T17:47:38ZDatabase error on upgrade to 6.7.3<div><p>Bradley,</p>
<p>I mistook Tim's message about it being READ-COMMITTED. I set it back to the default value (REPEATABLE -READ) and it works. Having binlog_format = ROW seems to be the only change necessary.</p>
<p>Thanks.</p>
<p>Jim</p></div>jkreuzigtag:help-archives.hannonhill.com,2010-02-09:Comment/35389252010-11-01T18:12:28Z2010-11-01T18:12:28ZDatabase error on upgrade to 6.7.3<div><p>Great, glad to hear it!</p>
<p>Thanks,<br />
Bradley</p></div>Bradley Wagner