Steve, ----- Original Message ----- From: "Orr, Steve" <[EMAIL PROTECTED]> To: "'Heikki Tuuri'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 3:27 AM Subject: RE: MySQL/InnoDB Hot Backups - What's a "binlog segment?"
> Thanks Heikki, > > I knew about the binlogs but that "segment" word confused me. > Now if I may "pester" you with 2 more questions... :-) ok, I will change the word 'segment' to 'file(s)'. > Quoting... "From the binlog segment you see if any of the .frm files changed > between the moment you took a .frm files backup and the moment ibbackup > finished its work." > > 1) Do you mean to say that you can actually look into the binlogs to > determine what .frm's changed? (If so how?) Or do you mean that backing up > the post ibbackup binlogs provides a snapshot containing changes that have > occurred since ibbackup began? You can look in the binlogs with the 'mysqlbinlog' program you find from the bin dir of a distribution. > 2) Why backup the .frm's and binlogs before and after ibbackup? Why not just > run ibbackup, backup the .frm's, do a mysqladmin flush-logs, backup the > prior (non-current) binlogs then purge them? Normally, you can just use the second backup of the .frm files as they are. But in theory it could happen that some .frm file changes just in the time between ibbackup finishes its work and the second backup of the .frm files is made. Then you can use the first backup of the .frm files and the binlog files to construct the right .frm file. Maybe it is best always to check if the first backup of the .frm files is identical to the second. If not, then look in the binlog file at positions immediately after the position which InnoDB prints when you restart mysqld on backed up data files. If there are ALTER TABLE etc. in it, you may need to manually construct some .frm files. The above procedure is awkward. It derives from the fact that the .frm files are not controlled transactionally. In future InnoDB may store the .frm files internally along with the table definition. Then you do not need to make any backups of .frm files any more, because they already are inside the backup of the ibdata files. This solution makes the .frm files transactional and also solves other problems caused by not in-sync .frm files. > Thanks again for your answers and your patience, > Steve Orr Regards, Heikki > -----Original Message----- > From: Heikki Tuuri [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 2:56 PM > To: [EMAIL PROTECTED] > Subject: Re: MySQL/InnoDB Hot Backups - What's a "binlog segment?" > > > Steve, > > the binlog is the MySQL logical log which it writes if you specify > > [mysqld] > log-bin > > in my.cnf. They are the files called 'hostname'-bin.00x in the datadir of > MySQL. They contain all INSERT, UPDATE, etc. SQL statements in an almost > human-readable form. > > The binlog is used to recover from a backup. Normally you should always > archive the binlog files if you have important data. The 'binlog segment' > means the binlog file(s) generated when the backup was running. > > Regards, > > Heikki > > ----- Original Message ----- > From: ""Orr, Steve"" <[EMAIL PROTECTED]> > Newsgroups: mailing.database.mysql > Sent: Wednesday, June 12, 2002 8:20 PM > Subject: MySQL/InnoDB Hot Backups - What's a "binlog segment?" > > > > I'm confused about the meaning of the help text from ibbackup --help. > > > > Here's the text: > > "You should make backups of the .frm files... both BEFORE and AFTER > ibbackup > > finishes its work, and also store the MySQL binlog segment which is > > generated between the moment you copy the .frm files to a backup and the > > moment ibbackup finishes its work... From the binlog segment you see if > any > > of the .frm files changed between the moment you took a .frm files backup > > and the moment ibbackup finished its work." > > > > So what exactly is the "binlog segment?" Is it some mysterious file or > > merely the text sections from the ibbackup output that refer to the lsn's? > > > > Here's some sample output: > > " . . . > > ibbackup: Found checkpoint at lsn 0 1418349381 > > ibbackup: Starting log scan from lsn 0 1418349056 > > . . . > > ibbackup: A copied database page was modified at 0 1418349381 > > ibbackup: Scanned log up to lsn 0 1418349381 > > ibbackup: Full backup completed!" > > > > > > Clueless in Montana, > > Steve Orr > > > > --------------------------------------------------------------------- > > 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 --------------------------------------------------------------------- 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
