hard disk crash: how to discover the db?

Hello

This is a real nightmare. A Mac crashed, the hard disk could
be saved. Right now it can't be booted.

But I don't know precisely the version of the OS
(most likely Mac X 10.4), nor the version of mysql (most
likely 5.3.x) and to make things worse I did not generate a
dump.

So is there any change to recover the db?
Could I just try to copy the relevant directory which
contains the db say to a linux machine and hope for the
best?

Any advice is strongly appreciated since a wiki is in that
db.


regards

Uwe Brauer


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

--_000_8064B8859E164B2FB3104AA23EEFC6B5nokiacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Try using the failed hdd as a slave in a Linux machine. You might find that=
the hdd won't boot to OS but may have enough in it to access the file syst=
em.

----- Reply message -----
From: "ext Uwe Brauer"
Date: Thu, Sep 9, 2010 21:31
Subject: hard disk crash: how to discover the db?
To: "mysql@lists.mysql.com"

Hello

This is a real nightmare. A Mac crashed, the hard disk could
be saved. Right now it can't be booted.

But I don't know precisely the version of the OS
(most likely Mac X 10.4), nor the version of mysql (most
likely 5.3.x) and to make things worse I did not generate a
dump.

So is there any change to recover the db?
Could I just try to copy the relevant directory which
contains the db say to a linux machine and hope for the
best?

Any advice is strongly appreciated since a wiki is in that
db.


regards

Uwe Brauer


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dandrew.2.moore@noki=
a.com


--_000_8064B8859E164B2FB3104AA23EEFC6B5nokiacom_--

Re: hard disk crash: how to discover the db?

andrew.2.moore@nokia.com wrote:
> Try using the failed hdd as a slave in a Linux machine.

>You might find that the hdd won't boot to OS but may have enough in it to access the file system.

I have done that already and I have access. But I don't know how to
extract the db (via dump) since the corresponding mysql server software
is not running. how can i tell linux to use the mysql db of the Mac?

Uwe Brauer

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

We do nightly backups at work just by taring the mysql directory. In
my environment, that is /var/lib/mysql.

Like this:

service mysql stop
cd /var/lib/mysql
rm -rf *
tar zxvf file.tar
rm -rf ib_logfile*
chown -R mysql.mysql
service mysql start

Something similar might work for you. Somebody with more MySQL
expertise than me can probably help you customize the process to your
environment.

Good luck!
G

On 9 September 2010 17:08, Uwe Brauer wrote:
> andrew.2.moore@nokia.com wrote:
>>
>> Try using the failed hdd as a slave in a Linux machine.
>
>> You might find that the hdd won't boot to OS but may have enough in it t=
o
>> access the file system.
>
> I have done that already and I have access. But I don't know how to extra=
ct
> the db (via dump) since the corresponding mysql server software is not
> running. how can i tell linux to use the mysql db of the Mac?
>
> Uwe Brauer
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> =A0http://lists.mysql.com/mysql?unsub=3Dgeorge.g.larson@gmai l.com
>
>

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: hard disk crash: how to discover the db?

On Thu, 2010-09-09 at 18:02 -0400, George Larson wrote:
> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.
>
> Like this:
>
> service mysql stop
> cd /var/lib/mysql
> rm -rf *
> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start
>
> Something similar might work for you. Somebody with more MySQL
> expertise than me can probably help you customize the process to your
> environment.
>
> Good luck!
> G

While this sounds like an idea, does anyone know if there are actual
version idiosyncrasies that need to be looked at first, such as which
version of mysql was run on the failed system vs which is running on the
rescue system?

> On 9 September 2010 17:08, Uwe Brauer wrote:
> > andrew.2.moore@nokia.com wrote:
> >>
> >> Try using the failed hdd as a slave in a Linux machine.
> >
> >> You might find that the hdd won't boot to OS but may have enough in it to
> >> access the file system.
> >
> > I have done that already and I have access. But I don't know how to extract
> > the db (via dump) since the corresponding mysql server software is not
> > running. how can i tell linux to use the mysql db of the Mac?
> >
> > Uwe Brauer
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:
> > http://lists.mysql.com/mysql?unsub=george.g.larson@gmail.com
> >
> >
>



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

Hi George, everybody!


George Larson wrote:
> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.
>=20
> Like this:
>=20
> service mysql stop
> cd /var/lib/mysql
> rm -rf *
^^^^^^^^
For your own benefit, I hope you don't do that on the machine on which
the (primary) DB server is installed.

> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start

The above procedure may work on a backup machine, to which you transfer
a "file.tar" which contains a database snapshot. So it is a recovery/
restore procedure, not the save/backup part.

Assuming the data are below /var/lib/mysql on the broken machine, and
that disk is mounted as /mnt, this would be like:

cd /mnt/var/lib/mysql
tar czvf /tmp/file.tar .

Take care not to damage that disk, or to use it for any other purpose,
until you have verified that your new database server could successfully
read and use all those data (do thorough checks!), and taken a full new
backup from it.

In general, I do not recommend to use file backups for a database, but
rather to use the database means (backup, dump, ...). However, after
your database machine broke, this isn't so easily possible.

>=20
> Something similar might work for you. Somebody with more MySQL
> expertise than me can probably help you customize the process to your
> environment.


To the original poster:
I know it sounds very hard and seems to ignore your trouble, but still:
A typical reply in DB support is
"If you have no backup, your data obviously are not important."

Everything can fail, both hard- and software: if your data are valuable,
you need a backup which is separated from the machine your data are on.
"Separated" might be an external disk that gets switched off, a tape
that is removed from its drive, another machine, just anything that
won't suffer even if your database server breaks terribly.
(To prevent questions: Mirrored disks or RAID systems are no backup, as
they are not separated.)

If backup is to external disk, my personal policy is to have at least
two of these, used in alternation: If total disaster strikes while one
is mounted and being written to, and that disaster affects all mounted
disks (data and current backup), I still have the previous backup.
Given current disk prices, one sleepless night will cost you more than
the second disk.

How often you do this backup is a decision you have to make yourself,
based on your update frequency and the possibility/cost to repeat the
changes that occurred since the last backup.


Regards,
Jörg

--=20
Joerg Bruehe, MySQL Build Team, joerg.bruehe@oracle.com
ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: hard disk crash: how to discover the db?

--001485e3ad3c7b9104048fe7aafe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

And still, nobody answered the man's actual question: can a Linux mysqld
read mac datafiles ?

I'd say "make a copy and try it". As long as you always keep a copy of the
original files, you're not risking anything. You might run into things
varying from incompatible MySQL versions to different endianness on your
files - I don't know. Try and you'll see.

Worst case scenario, get an identical mac with an identical mysql and copy
the files to that.


On Fri, Sep 10, 2010 at 10:57 AM, Joerg Bruehe wro=
te:

> Hi George, everybody!
>
>
> George Larson wrote:
> > We do nightly backups at work just by taring the mysql directory. In
> > my environment, that is /var/lib/mysql.
> >
> > Like this:
> >
> > service mysql stop
> > cd /var/lib/mysql
> > rm -rf *
> ^^^^^^^^
> For your own benefit, I hope you don't do that on the machine on which
> the (primary) DB server is installed.
>
> > tar zxvf file.tar
> > rm -rf ib_logfile*
> > chown -R mysql.mysql
> > service mysql start
>
> The above procedure may work on a backup machine, to which you transfer
> a "file.tar" which contains a database snapshot. So it is a recovery/
> restore procedure, not the save/backup part.
>
> Assuming the data are below /var/lib/mysql on the broken machine, and
> that disk is mounted as /mnt, this would be like:
>
> cd /mnt/var/lib/mysql
> tar czvf /tmp/file.tar .
>
> Take care not to damage that disk, or to use it for any other purpose,
> until you have verified that your new database server could successfully
> read and use all those data (do thorough checks!), and taken a full new
> backup from it.
>
> In general, I do not recommend to use file backups for a database, but
> rather to use the database means (backup, dump, ...). However, after
> your database machine broke, this isn't so easily possible.
>
> >
> > Something similar might work for you. Somebody with more MySQL
> > expertise than me can probably help you customize the process to your
> > environment.
>
>
> To the original poster:
> I know it sounds very hard and seems to ignore your trouble, but still:
> A typical reply in DB support is
> "If you have no backup, your data obviously are not important."
>
> Everything can fail, both hard- and software: if your data are valuable,
> you need a backup which is separated from the machine your data are on.
> "Separated" might be an external disk that gets switched off, a tape
> that is removed from its drive, another machine, just anything that
> won't suffer even if your database server breaks terribly.
> (To prevent questions: Mirrored disks or RAID systems are no backup, as
> they are not separated.)
>
> If backup is to external disk, my personal policy is to have at least
> two of these, used in alternation: If total disaster strikes while one
> is mounted and being written to, and that disaster affects all mounted
> disks (data and current backup), I still have the previous backup.
> Given current disk prices, one sleepless night will cost you more than
> the second disk.
>
> How often you do this backup is a decision you have to make yourself,
> based on your update frequency and the possibility/cost to repeat the
> changes that occurred since the last backup.
>
>
> Regards,
> Jörg
>
> --
> Joerg Bruehe, MySQL Build Team, joerg.bruehe@oracle.com
> ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
> Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
> Amtsgericht Muenchen: HRA 95603
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dvegivamp@tuxera.b=
e
>
>


--=20
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--001485e3ad3c7b9104048fe7aafe--

Re: hard disk crash: how to discover the db?

>>>>> On Fri, 10 Sep 2010 10:57:54 +0200, Joerg Bruehe wrote:

> Hi George, everybody!
> George Larson wrote:
>> We do nightly backups at work just by taring the mysql directory. In
>> my environment, that is /var/lib/mysql.
>>
>> Like this:
>>
>> service mysql stop
>> cd /var/lib/mysql
>> rm -rf *




> To the original poster:
> I know it sounds very hard and seems to ignore your trouble, but still:
> A typical reply in DB support is
> "If you have no backup, your data obviously are not important."

Please no more "salt in my wounds". I keep telling me that
myself and the only lame excuse I have is that the dump
command I was used to in Linux did not work out in Mac and I
did not bother to figure out why.

Uwe Brauer


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

>>>>> On Thu, 09 Sep 2010 18:02:09 -0400, George Larson wrote:

> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.

> Like this:

> service mysql stop
> cd /var/lib/mysql
> rm -rf *
> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start

> Something similar might work for you. Somebody with more MySQL
> expertise than me can probably help you customize the process to your
> environment.

Ok thanks. What I am afraid of is that in on of these OS,
their might be some other configuration files, which might
be located apart from the main directory say in /etc and
then I should copy them as well.

Would it be necessary in Linux to generate the db and its
users first?

Uwe Brauer


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

>>>>> On Fri, 10 Sep 2010 04:43:39 -0400, Mike McMullin wrote:

> On Thu, 2010-09-09 at 18:02 -0400, George Larson wrote:
>>
>> Good luck!
>> G

> While this sounds like an idea, does anyone know if there are actual
> version idiosyncrasies that need to be looked at first,
> such as which version of mysql was run on the failed
> system vs which is running on the rescue system?

Precisely like some information say written in
/etc/mysql.conf or something like this.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

Uwe Brauer wrote:
>>>>>> On Thu, 09 Sep 2010 18:02:09 -0400, George Larson wrote:
>
> > We do nightly backups at work just by taring the mysql directory. In
> > my environment, that is /var/lib/mysql.
>
> > Like this:
>
> > service mysql stop
> > cd /var/lib/mysql
> > rm -rf *
> > tar zxvf file.tar
> > rm -rf ib_logfile*
> > chown -R mysql.mysql
> > service mysql start
>
> > Something similar might work for you. Somebody with more MySQL
> > expertise than me can probably help you customize the process to your
> > environment.
>
> Ok thanks. What I am afraid of is that in on of these OS,
> their might be some other configuration files, which might
> be located apart from the main directory say in /etc and
> then I should copy them as well.
>
> Would it be necessary in Linux to generate the db and its
> users first?
>
> Uwe Brauer
>
The only one I know of, for my environment, is /etc/my.cnf. I believe
that it can be located elsewhere but you could just use 'find' to find
it. I've broken my dev. MySQL many, many times and that's the only file
I know about outside of my data directory. :)

I don't have any good ideas about discerning precisely what version of
MySQL was running, though.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

did I miss the joke here? Why does this backup script look SO wrong,
and very malicious?

service mysql stop -- stopping mysql... that's fine.
cd /var/lib/mysql -- changing directories to the /var/lib/mysql, ok...
fine
rm -rf * -- WHAT? WHY ARE YOU REMOVING RECUSIVLY and FORCING DELETES on
all the MySQL files?? are you insane? this is going to make a bad day
for a lot of people
tar zxvf file.tar -- Wait, you just blew away all the files in
the /var/lib/mysql directory, how can you extract a tar file, when it
does not exist, since you just deleted everything?????

anyway, I hope I missed the joke here, or missed something...

Steve.


On Thu, 2010-09-09 at 18:02 -0400, George Larson wrote:
> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.
>
> Like this:
>
> service mysql stop
> cd /var/lib/mysql
> rm -rf *
> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start
>
> Something similar might work for you. Somebody with more MySQL
> expertise than me can probably help you customize the process to your
> environment.
>
> Good luck!
> G
>
> On 9 September 2010 17:08, Uwe Brauer wrote:
> > andrew.2.moore@nokia.com wrote:
> >>
> >> Try using the failed hdd as a slave in a Linux machine.
> >
> >> You might find that the hdd won't boot to OS but may have enough in it to
> >> access the file system.
> >
> > I have done that already and I have access. But I don't know how to extract
> > the db (via dump) since the corresponding mysql server software is not
> > running. how can i tell linux to use the mysql db of the Mac?
> >
> > Uwe Brauer
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:
> > http://lists.mysql.com/mysql?unsub=george.g.larson@gmail.com
> >
> >
>


--

Steve Staples
Web Application Developer
519.258.2333 x8414


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

>>>>> On Fri, 10 Sep 2010 10:01:30 -0400, george larson wrote:


> The only one I know of, for my environment, is
> /etc/my.cnf. I believe that it can be located
> elsewhere but you could just use 'find' to find it.
> I've broken my dev. MySQL many, many times and that's
> the only file I know about outside of my data
> directory. :)

> I don't have any good ideas about discerning precisely
> what version of MySQL was running, though.


Ok, I hope this holds for the Mac Os as well but I will
certainly search for this file, thanks.

Uwe


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

Hi Steve.

Steve Staples wrote:
> did I miss the joke here? Why does this backup script look SO wrong,
> and very malicious?
>
> service mysql stop -- stopping mysql... that's fine.
> cd /var/lib/mysql -- changing directories to the /var/lib/mysql, ok...
> fine
> rm -rf * -- WHAT? WHY ARE YOU REMOVING RECUSIVLY and FORCING DELETES on
> all the MySQL files?? are you insane? this is going to make a bad day
> for a lot of people
> tar zxvf file.tar -- Wait, you just blew away all the files in
> the /var/lib/mysql directory, how can you extract a tar file, when it
> does not exist, since you just deleted everything?????
>
> anyway, I hope I missed the joke here, or missed something...
>
> Steve.
>
>
> On Thu, 2010-09-09 at 18:02 -0400, George Larson wrote:
>> We do nightly backups at work just by taring the mysql directory. In
>> my environment, that is /var/lib/mysql.
>>
>> Like this:
>>
>> service mysql stop
>> cd /var/lib/mysql
>> rm -rf *
>> tar zxvf file.tar
>> rm -rf ib_logfile*
>> chown -R mysql.mysql
>> service mysql start
>>
>> Something similar might work for you. Somebody with more MySQL
>> expertise than me can probably help you customize the process to your
>> environment.
>>
>> Good luck!
>> G
>>
Nope. No joke. It's a process that's been in place long before I got
here and it is done, with varying frequency, by the entire staff of
developers here. It seemed a little odd to me at first also, but I was
told only that it was faster than any other method. It might make a
little more sense if you realize that it isn't a script, it's just me
listing the commands that are used. This process is on /my/
(development) environment, so hasn't the potential to make bad days for
anybody except me.

And, yeah, I suppose I could have gone with a "tar zxvf
/path/to/file.tar" but I didn't expect OP was going to tar up his
database first, so it seemed good enough for example purposes.

Sorry for any alarming confusion.
G

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

On 9/10/2010 10:01 AM, george larson wrote:
>
> Uwe Brauer wrote:
> ...
> The only one I know of, for my environment, is /etc/my.cnf. I believe
> that it can be located elsewhere but you could just use 'find' to find
> it. I've broken my dev. MySQL many, many times and that's the only file
> I know about outside of my data directory. :)
>
> I don't have any good ideas about discerning precisely what version of
> MySQL was running, though.
>

The error log will have the version information. Each successful startup
includes something similar to

100910 7:50:30 [Note] mysqld: ready for connections.
Version: '5.1.48-enterprise-gpl-advanced' socket: '' port: 3306 MySQL
Enterprise Server - Advanced Edition (GPL)

For more information on how to locate the error log:
http://dev.mysql.com/doc/refman/5.1/en/error-log.html

--
Shawn Green
MySQL Principal Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

Shawn Green (MySQL) wrote:
> On 9/10/2010 10:01 AM, george larson wrote:
>>
>> Uwe Brauer wrote:
>> ...
>> The only one I know of, for my environment, is /etc/my.cnf. I believe
>> that it can be located elsewhere but you could just use 'find' to find
>> it. I've broken my dev. MySQL many, many times and that's the only file
>> I know about outside of my data directory. :)
>>
>> I don't have any good ideas about discerning precisely what version of
>> MySQL was running, though.
>>
>
> The error log will have the version information. Each successful
> startup includes something similar to
>
> 100910 7:50:30 [Note] mysqld: ready for connections.
> Version: '5.1.48-enterprise-gpl-advanced' socket: '' port: 3306
> MySQL Enterprise Server - Advanced Edition (GPL)
>
> For more information on how to locate the error log:
> http://dev.mysql.com/doc/refman/5.1/en/error-log.html
>
That's a neat trick and I don't mean to steal the thread but that didn't
work for me:

---
:/var/lib/mysql # head mysqld.log
100910 12:50:09 mysqld_safe Starting mysqld daemon with databases from
/var/lib/mysql
100910 12:50:09 [Warning] option 'table_cache': unsigned value 536870912
adjusted to 524288
100910 12:50:09 [Warning] The syntax '--log_slow_queries' is deprecated
and will be removed in MySQL 7.0. Please use
'--slow_query_log'/'--slow_query_log_file' instead.
100910 12:50:09 [Warning] Changed limits: max_open_files: 65535
max_connections: 50 table_cache: 32737
100910 12:50:09 [Note] Plugin 'ndbcluster' is disabled.
100910 12:50:09 [Note] Plugin 'FEDERATED' is disabled.
---

I'm going to comb through my 'my.cnf' to see if it might have somehow
been disabled.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: hard disk crash: how to discover the db?

--001485f629cae84f14048feab05d
Content-Type: text/plain; charset=ISO-8859-1

I agree with everyone else here.

This NOT a backup job listed here. it is a RESTORE job that is restoring
data previously backed up into a file named 'file.tar' (should probably be
file.tar.gz or file.tgz anyway).

This sequence of commands should never be run on a server that you are
wanting to backup (development, testing, stage and/or production).

> service mysql stop
> cd /var/lib/mysql
> *rm -rf * (this will delete all your MySQL data)*
> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start



-JW



On Fri, Sep 10, 2010 at 9:51 AM, Steve Staples wrote:

> did I miss the joke here? Why does this backup script look SO wrong,
> and very malicious?
>
> service mysql stop -- stopping mysql... that's fine.
> cd /var/lib/mysql -- changing directories to the /var/lib/mysql, ok...
> fine
> rm -rf * -- WHAT? WHY ARE YOU REMOVING RECUSIVLY and FORCING DELETES on
> all the MySQL files?? are you insane? this is going to make a bad day
> for a lot of people
> tar zxvf file.tar -- Wait, you just blew away all the files in
> the /var/lib/mysql directory, how can you extract a tar file, when it
> does not exist, since you just deleted everything?????
>
> anyway, I hope I missed the joke here, or missed something...
>
> Steve.
>
>
> On Thu, 2010-09-09 at 18:02 -0400, George Larson wrote:
> > We do nightly backups at work just by taring the mysql directory. In
> > my environment, that is /var/lib/mysql.
> >
> > Like this:
> >
> > service mysql stop
> > cd /var/lib/mysql
> > rm -rf *
> > tar zxvf file.tar
> > rm -rf ib_logfile*
> > chown -R mysql.mysql
> > service mysql start
> >
> > Something similar might work for you. Somebody with more MySQL
> > expertise than me can probably help you customize the process to your
> > environment.
> >
> > Good luck!
> > G
> >
> > On 9 September 2010 17:08, Uwe Brauer wrote:
> > > andrew.2.moore@nokia.com wrote:
> > >>
> > >> Try using the failed hdd as a slave in a Linux machine.
> > >
> > >> You might find that the hdd won't boot to OS but may have enough in it
> to
> > >> access the file system.
> > >
> > > I have done that already and I have access. But I don't know how to
> extract
> > > the db (via dump) since the corresponding mysql server software is not
> > > running. how can i tell linux to use the mysql db of the Mac?
> > >
> > > Uwe Brauer
> > >
> > > --
> > > MySQL General Mailing List
> > > For list archives: http://lists.mysql.com/mysql
> > > To unsubscribe:
> > > http://lists.mysql.com/mysql?unsub=george.g.larson@gmail.com
> > >
> > >
> >
>
>
> --
>
> Steve Staples
> Web Application Developer
> 519.258.2333 x8414
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=johnny@pixelated.net
>
>


--
-----------------------------
Johnny Withers
601.209.4985
johnny@pixelated.net

--001485f629cae84f14048feab05d--

Re: hard disk crash: how to discover the db?

--001485f1e71c1d463e048feae97c
Content-Type: text/plain; charset=ISO-8859-1

If you still have the mysqld binary and you _think_ it is version
5.3.something, you could try this:

strings /usr/libexec/mysqld | grep "5.3.*"

The version # should be somewhere near the top of the output. (Is on my copy
anyway, of 5.0.x)


------------------------------

*Johnny Withers*
jwithers@ecashsoftware.com
601.919.2275 x112
[image: eCash Software Systems]


On Fri, Sep 10, 2010 at 12:00 PM, george larson
wrote:

>
>
> Shawn Green (MySQL) wrote:
> > On 9/10/2010 10:01 AM, george larson wrote:
> >>
> >> Uwe Brauer wrote:
> >> ...
> >> The only one I know of, for my environment, is /etc/my.cnf. I believe
> >> that it can be located elsewhere but you could just use 'find' to find
> >> it. I've broken my dev. MySQL many, many times and that's the only file
> >> I know about outside of my data directory. :)
> >>
> >> I don't have any good ideas about discerning precisely what version of
> >> MySQL was running, though.
> >>
> >
> > The error log will have the version information. Each successful
> > startup includes something similar to
> >
> > 100910 7:50:30 [Note] mysqld: ready for connections.
> > Version: '5.1.48-enterprise-gpl-advanced' socket: '' port: 3306
> > MySQL Enterprise Server - Advanced Edition (GPL)
> >
> > For more information on how to locate the error log:
> > http://dev.mysql.com/doc/refman/5.1/en/error-log.html
> >
> That's a neat trick and I don't mean to steal the thread but that didn't
> work for me:
>
> ---
> :/var/lib/mysql # head mysqld.log
> 100910 12:50:09 mysqld_safe Starting mysqld daemon with databases from
> /var/lib/mysql
> 100910 12:50:09 [Warning] option 'table_cache': unsigned value 536870912
> adjusted to 524288
> 100910 12:50:09 [Warning] The syntax '--log_slow_queries' is deprecated
> and will be removed in MySQL 7.0. Please use
> '--slow_query_log'/'--slow_query_log_file' instead.
> 100910 12:50:09 [Warning] Changed limits: max_open_files: 65535
> max_connections: 50 table_cache: 32737
> 100910 12:50:09 [Note] Plugin 'ndbcluster' is disabled.
> 100910 12:50:09 [Note] Plugin 'FEDERATED' is disabled.
> ---
>
> I'm going to comb through my 'my.cnf' to see if it might have somehow
> been disabled.
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=johnny@pixelated.net
>
>


--
-----------------------------
Johnny Withers
601.209.4985
johnny@pixelated.net

--001485f1e71c1d463e048feae97c--

Re: hard disk crash: how to discover the db?

On Fri, 2010-09-10 at 15:57 +0200, Uwe Brauer wrote:
> >>>>> On Fri, 10 Sep 2010 04:43:39 -0400, Mike McMullin wrote:
>
> > On Thu, 2010-09-09 at 18:02 -0400, George Larson wrote:
> >>
> >> Good luck!
> >> G
>
> > While this sounds like an idea, does anyone know if there are actual
> > version idiosyncrasies that need to be looked at first,
> > such as which version of mysql was run on the failed
> > system vs which is running on the rescue system?
>
> Precisely like some information say written in
> /etc/mysql.conf or something like this.

I was thinking version of mysql, but yes where things are installed to
as well, I know that the openSuSE version puts stuff in a different
location than the Ubuntu version of the same software version.



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re:hard disk crash: how to discover the db?

--000e0cd56a8068171a048ff8454d
Content-Type: text/plain; charset=ISO-8859-1

Have you tried testdisk or photorec data recovery application.follow this
link www.cgsecurity.org/

thanks

--000e0cd56a8068171a048ff8454d--

no success (was: hard disk crash: how to discover the db?)

>>>>> On Thu, 09 Sep 2010 18:02:09 -0400, George Larson wrote:

> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.

> Like this:

> service mysql stop
> cd /var/lib/mysql
> rm -rf *
> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start

I have followed these steps and it seems not to work.
I have re installed the mediawiki software and then I tried
to open the corresponding wikipage, but only see empty pages.
There are several reasons for this:

- when the hard disk crashed the database was damaged,
as a matter of fact when I have a look into the
/var/lib/mysql/maqwiki
directory most of the files are very small in size with the
exception of searchindex.MYD and searchindex.MYI. I
have no idea whether this is "normal".

- I did not do the recover process correctly. Is there
any "hardcore" mysql command I could use to check the
database?

- the connection between the mediawiki conf and the
data base is broken. I will ask in the mediawiki page
about this.

Any advice and help is very much appreciated.

Uwe Brauer


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

RE: no success (was: hard disk crash: how to discover the db?)

With PHP, a blank page usually means it's generating an error, but not disp=
laying it in the browser; this is often disabled for security reasons, but =
makes debugging harder. First step should be to get PHP to spit out the ac=
tual error. There should probably be a setting in the mediawiki configurat=
ion for this, or see the PHP docs for error reporting.

-----Original Message-----
From: Uwe Brauer [mailto:oub.oub.oub@gmail.com] On Behalf Of Uwe Brauer
Sent: Monday, September 13, 2010 10:35 AM
To: George Larson
Cc: andrew.2.moore@nokia.com; mysql@lists.mysql.com
Subject: no success (was: hard disk crash: how to discover the db?)

>>>>> On Thu, 09 Sep 2010 18:02:09 -0400, George Larson ail.com> wrote:

> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.

> Like this:

> service mysql stop
> cd /var/lib/mysql
> rm -rf *
> tar zxvf file.tar
> rm -rf ib_logfile*
> chown -R mysql.mysql
> service mysql start

I have followed these steps and it seems not to work.
I have re installed the mediawiki software and then I tried
to open the corresponding wikipage, but only see empty pages.
There are several reasons for this:

- when the hard disk crashed the database was damaged,
as a matter of fact when I have a look into the
/var/lib/mysql/maqwiki
directory most of the files are very small in size with the
exception of searchindex.MYD and searchindex.MYI. I
have no idea whether this is "normal".

- I did not do the recover process correctly. Is there
any "hardcore" mysql command I could use to check the
database?

- the connection between the mediawiki conf and the
data base is broken. I will ask in the mediawiki page
about this.

Any advice and help is very much appreciated.

Uwe Brauer


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgtowey@ffn.com


This message contains confidential information and is intended only for the=
individual named. If you are not the named addressee, you are notified th=
at reviewing, disseminating, disclosing, copying or distributing this e-mai=
l is strictly prohibited. Please notify the sender immediately by e-mail i=
f you have received this e-mail by mistake and delete this e-mail from your=
system. E-mail transmission cannot be guaranteed to be secure or error-fre=
e as information could be intercepted, corrupted, lost, destroyed, arrive l=
ate or incomplete, or contain viruses. The sender therefore does not accept=
liability for any loss or damage caused by viruses or errors or omissions =
in the contents of this message, which arise as a result of e-mail transmis=
sion. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089,=
USA, FriendFinder.com

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: SOLVED!!!!Re: hard disk crash: how to discover the db?

Uwe Brauer wrote:
>
> What I had to do in addition was to copy the ibdata1
> *then* I recovered the content of the db.
>
> Thanks a lot
>
>
> Uwe Brauer
>
Uwe,

Congratulations! That's great news! Sorry I didn't know to mention
that step. Where is your 'ibdata1'? Mine is in '/var/lib/mysql' so,
for me, it gets included in the steps I mentioned.

I'm glad to hear that you figured it out!
G

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org