Re: Emergency follow up... Re: Request for comments on upgrade plan

[Anatoly Pidruchny]

Wilersh,

You said you "did a rolling restart with --initial on each node". You 
did not mention if you restarted the management node. Did you restart 
the management node before doing this? If you did not restart the 
management node then this is why your config file changes did not take 
effect. Just checking.

Regards,
Anatoly.
> Could my issues be a result of having to set 
> TimeBetweenLocalCheckpoints really low (5) and NoOfFragmentLogFiles 
> (300) really high during my restore? After the restore I commented 
> those settings out of config.ini and did a rolling restart with 
> --initial on each node. I believe that sets them back to a default 
> setting, which seemed to work for me before.
>
> Thanks
>
> Eric
>
>
> On Nov 13, 2007, at 11:25 AM, Wilersh wrote:
>
>> Hi all,
>>
>> I must have missed something in my upgrade from 5.0.26 to 5.0.45. 
>> Everything went well with the upgrade, I restored from backups as 
>> Bond suggested below and we are up and running. Thanks Bond!
>>
>> But, I discovered this morning that the hardrive on one node had 
>> filled and quit working, and the other node was close to being full.
>>
>> I was able to clear out some space for now, and I'm starting to read 
>> up on what may be happening, but can anyone on this list point me to 
>> what I missed about this upgrade that would cause my disk to fill. It 
>> appears there is a directory in /var/lib/mysql-cluster/ndb_?_fs/D? 
>> that I didn't notice before, but is quite full of bits.
>>
>> Thanks for any assistance.
>>
>> (Sweating profusely...)
>>
>> Eric
>>
>>
>>
>> On Nov 9, 2007, at 2:42 PM, Bond Masuda wrote:
>>
>>> Hi Eric,
>>>
>>> I did this upgrade not so long ago. I would actually recommend that you
>>> scrap everything in /var/lib/mysql-cluster/data on the data nodes 
>>> and do a
>>> init and restore (from hotbackups or SQL dump).
>>>
>>> I can't remember the *exact* reason, but I recall that there are 
>>> some data
>>> type incompatibilities (I think it was related to ENUM) between 
>>> 5.0.26 and
>>> 5.0.45. Hence, I'm recommending a restore from either a hotbackup or 
>>> SQL
>>> dump.
>>>
>>> I recommend going reviewing the release notes and specifically 
>>> looking at
>>> the section "incompatible changes" to see how the upgrade will 
>>> affect your
>>> systems. If you are 100% the incompatible changes will not affect 
>>> you, then
>>> maybe you can get away without doing a restore.
>>>
>>> In addition, I recall an ABI incompatibility, so if you have some 
>>> programs
>>> linked to the 5.0.26 libraries, they *might* have issues with the 
>>> new ones.
>>>
>>> I don't have the specific facts in front of me, just going off 
>>> memory. I
>>> found the necessary information by reviewing the release notes. Hope 
>>> that
>>> helps a little bit...
>>>
>>> -Bond
>>>
>>> -----Original Message-----
>>> From: Wilersh [mailto:wilersh@stripped]
>>> Sent: Friday, November 09, 2007 11:27 AM
>>> To: cluster@stripped
>>> Subject: Request for comments on upgrade plan
>>>
>>> Hi folks,
>>>
>>> I planning on upgrading my 5.0.26 cluster to 5.0.45 on Monday. I
>>> thought I'd run my initial plan by the helpful folks on this list for
>>> comments, if you had a moment.
>>>
>>> My cluster has 3 machines, one for management, and two others, each
>>> running ndbd and mysqld. This is on OS X Server 10.4.7.
>>>
>>> Cluster backup:
>>> ndb_mgm -e 'start backup'
>>>
>>> Mysqldump of all databases (to be extra safe), after going to single
>>> user mode on the management node, on a mysqld node:
>>> mysqldump -u assetmanager -p --all-databases > ~admin/Desktop/
>>> mysq_db_20071112.sql
>>>
>>> Install the 64-bit package install of 5.0.45. on each node.
>>>
>>> Copy the mysql/data/ directory from my old install into the new
>>> install on the two mysqd/ndbd nodes.
>>>
>>> Restart the cluster as usual:
>>> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
>>> ndbd
>>> mysqd_safe &
>>>
>>> I also wondering if I need/should run the mysql_upgrade command
>>> afterwards?
>>> Is is documented somewhere how to properly restore the cluster from
>>> the mysqldump of --all-databases I did above? ( Just in case... )
>>> Should I dump tables individually for granular recovery instead?
>>> Anyone see major flaws or something I forgot?
>>> Thanks for any comments!
>>> Eric
>>>
>>>
>>>
>>>
>>
>
>