At 11:28 AM 07/04/2001 , you wrote:
>hi.
>
>w/r/t your first question: mysqldump just generates a text file containing
>the sql statements necessary to recreate the dumped table(s).
>if you use mysqldump -uuser -p > dumpfile.txt you can open it in vi or
>notepad and edit it if desired...
>the error about the table existing is because the generated file by default
>has the table creation statement in it.
>use mysql -t or mysql --no-create-info to eliminate this.
>run mysqldump with no arguments to see the full usage info.
>the duplicate keys error would most likely be because you have existing rows
>in your table that conflict with the insert statements...pipe the output to
>a file instead of straight to mysql(if that's what you're doing), then check
>out what exactly's failing.
I must have missed something in your explanation above:
I did the following:
mysqdump -u jimmyjoe--password=123pwhere thedbname > my_dump_file.txt
Then:
mysql -u jimmyjoe--password=123pwhere thedbname < my_dump_file.txt > error.txt
ERROR 1050 at line 10: Table 'bb_instructor' already exists
ls -al error.txt (= 0 bytes)
Line 10 (thru 20) says:
10 CREATE TABLE bb_instructor (
11 id int(11) DEFAULT '0' NOT NULL auto_increment,
12 thread int(11),
13 message text,
14 subject varchar(80),
15 author int(11),
16 when datetime,
17 lastactivity datetime,
18 replies int(11),
19 PRIMARY KEY (id)
20 );
I understand this, I just dumped the database. I guess what I'm missing is
that you can't re-create an existing database for whatever reason, corrupt,
customer scrambled data, or anything. So. You can't overwrite an existing
database using mysql?
If I delete all the associated *.frm, *.MYD, and *.MYI files, and run the
same command again, I get the duplicate keys error.
So, what am I learning here? Is this database damaged in the first place?
Even tho it functions properly as far as all the Perl scripts which manage
it. Or is there a Perl script which is managing something wrong?
Like I said before, this is a learning exercise, I'm trying to fill the
holes in my understanding between the manual and actual command execution.
-- more below --
>2nd question:
>replication's good if you need a 'live' secondary...for instance, at my last
>job we used a replicated secondary database to run intensive up-to-date
>statistic queries that otherwise would have locked important tables. (pre
>row-level locking table types, of course).
I'll need to read more about this feature.
>if you just want backups made at intervals, i'd just dump all/important
>tables to a file periodically via cron.
You mean something like this?
50 4 * * * cp -af /var/lib/mysql/test/*.*
/var/lib/mysql/backup-hold/test/ > /dev/null 2>&1
Thanks for your help, I'm not totally stupid, it's just that I seem to have
a fog in front of my eyes.
Joe
>that's just me.
>
>hth.
>
>-ravi.
>
>-----Original Message-----
>From: Joe Taraba [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, July 04, 2001 1:48 PM
>To: [EMAIL PROTECTED]
>Subject: Replication, update log, mysqldump???
>
>
>Hi;
>
>I'm trying to learn MySQL, having some difficulties understanding backup
>strategies.
>
>mysql Ver 9.38 Distrib 3.22.32, for pc-linux-gnu (i686)
>
>Where is the documentation (besides man pages) for mysql Ver 3.22.32
>
>According to the the 3.23.29 online docs it appears that there are four
>ways to go:
>
>Replication
>update log
>mysqldump
>mysqlhotcopy script
>
>The mysqlhotcopy script is apparently not available for my version so I
>manually backed-up (copied) all the *.frm, *.MYD, and *.MYI files for each
>database, so I know the usefulness of that approach--sort'a.
>
>I tried mysqldump on an existing database, and then tried to load it back
>and got several types of errors.
>
>1. Table exists errors, so I deleted all the *.frm, *.MYD, and *.MYI files
>for that database.
>2. I tried to load the dumpfile again and got errors about duplicate keys.
>
>This database is not visible to anyone right now, so there were no
>activities going on. This is an exact copy of a functioning customer
>database.
>
>I haven't tried using the update log, nor do I fully understand it's
>usefulness. The online docs say not to use it for versions later than
><quote> Now that master-slave internal replication is available starting in
>Version 3.23.15, using the update log to implement replications is not
>recommended. See section 11 Replication in MySQL. </quote>
>
>Replication, I guess is not available for my version either. I glanced
>briefly at the docs on Replication--it looks pretty nifty.
>
>So I guess there are actually two questions here:
>
>1. Why the errors from mysqldump (reload) from an apparently perfectly good
>database?
>
>2. Should I upgrade my version of MySQL and follow the Replication
>procedures?
>
>A ton of thanks from anyone not taking a holiday (USA) today.
>
>Joe
>
>
>---------------------------------------------------------------------
>Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
>To request this thread, e-mail <[EMAIL PROTECTED]>
>To unsubscribe, e-mail <[EMAIL PROTECTED]>
>Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
