MySql Import speed(Was mysql version OSX)

[Mike Matthews]

Thanks Clifford,

If I get my hands back on the box again, I'll let you know.  But thanks for the info, much appreciated, and I agree about the smelly support.

Mike

 

On 22 Dec 2010, at 00:57, CLIFFORD ILKAY wrote:

> On 12/21/2010 05:54 PM, Mike Matthews wrote:
>> The big issue here was this BigRedBox, did I mention this before?  We
>> don't know jack diddly about it, and even less about the admin
>> passwords, etc.  But we took out the HD and then had the data out
>> anyway.
> 
> For future reference, once you have physical access to the machine, you don't need to care about admin passwords. Unless they put a password on the boot loader, which is very unlikely, you can boot in single user mode, change the root password to whatever you want, reboot, and you'll be the new king of the domain. If there is a password on the boot loader, it's still pretty easy to work around. You put that drive into another machine, boot from another device, copy the line in /etc/shadow corresponding to the user for whom you want to change the password from a machine where you know the password, and overwrite that line in /etc/shadow in the drive where you don't know the password for that user.
> 
>> The problem was that the mail server software services wouldn't
>> start, file sharing services wouldn't start, so now you know.
> 
> Sounds suspiciously like a full filesystem problem. If you mounted all the filesystems on that drive and do a "df -h", you'll probably see "100%" in the "Use%" column for one of the filesystems. It could also be stale lock files preventing the daemons from starting because of a dirty shutdown. Again, for future reference, try:
> 
> /etc/init.d/<daemon name> start
> 
> and see what, if anything, is echoed to the console. You could monitor the log in real-time by doing:
> 
> tail -f /var/log/messages (or whatever the log file is for that particular daemon - just list the log files in /var/log)
> 
> That often provides good clues on what is happening.
> 
>> Every
>> day that goes by, the data becomes out of date and more irrelevant.
>> They have all the new email, but no old stuff at all, as it was
>> accessed by webmail.  There is no support for this box, unpaid
>> support invoices, a bankrupt company, etc, a whole nasty can of
>> worms.
> 
> You don't need no stinkin' support from a "vendor" if you understand Linux or if you know whom to ask. :)
> 
>> I got the data imported in about 4 hours in the end by
>> turning the log-output=NONE, but interestingly on a Win32 box and
>> MySql v5.1, the import struggled to get anywhere, but my MBP and with
>> v5.58, it did it in about 4 hours.
>> 
>> I just used the WorkBench and the Import section, seemed simple
>> enough, which suits me, just a pain that I had to update the one file
>> and make the my.cnf file which is just plain stoopid.
>> 
>> All academic as the customer bit the bullet, paid the old support
>> invoices, and will hopefully get the BigRedBox, that really is the
>> name, and it is Red, back working so that the old historical email
>> can be pulled out.  The sql data is very obfuscated when I looked,
>> mostly BLOBs and just pkeys, so impossible to make a valid judgement
>> in a few hours.
> 
> My inclination would be to get it working first and then figure out a migration strategy when you're not under the gun. It should be quite feasible to get it working again.
> -- 
> Regards,
> 
> Clifford Ilkay
> Dinamis
> 1419-3266 Yonge St.
> Toronto, ON
> Canada  M4N 3P6
> 
> <http://dinamis.com>
> +1 416-410-3326
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com