Re: InnoDB and rsync

2011-01-26 Thread Johan De Meersman
On Wed, Jan 26, 2011 at 6:58 AM, Robinson, Eric eric.robin...@psmnv.comwrote:

   You need to quiesce the InnoDb background threads. One technique is
   mentioned here:
   http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablesp
  aces.html
  
   Look for the section talking about clean backups.
 
  Now we're talkin. I'll check it out.
 
 

 I read that section but it is not at all clear (1) how one quiesces the
 InnoDB background threads, or (2) if there is a way to keep them
 quiesced while the backup is in progress.


From what I see there:

 You can make a clean backup .ibd file using the following method:

1.

Stop all activity from the 
 *mysqld*http://dev.mysql.com/doc/refman/5.5/en/mysqld.htmlserver and commit 
 all transactions.
2.

Wait until SHOW ENGINE INNODB 
 STATUShttp://dev.mysql.com/doc/refman/5.5/en/show-engine.htmlshows that 
 there are no active transactions in the database, and the main
thread status of InnoDB is Waiting for server activity. Then you can
make a copy of the .ibd file.

 I would assume that flush tables with read lock would work for 1. and
then you wait for 2. to happen. Probably shouldn't take very long,
especially in the quiet moments.


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


RE: InnoDB and rsync

2011-01-26 Thread Robinson, Eric
 

  You need to quiesce the InnoDb background threads. One
technique is
  mentioned here:
 
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablesp
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablesp 
 aces.html
 
  Look for the section talking about clean backups.

 Now we're talkin. I'll check it out.




I read that section but it is not at all clear (1) how one
quiesces the
InnoDB background threads, or (2) if there is a way to keep them
quiesced while the backup is in progress.



From what I see there: 


You can make a clean backup .ibd file using the following
method: 

1.  Stop all activity from the mysqld
http://dev.mysql.com/doc/refman/5.5/en/mysqld.html  server and commit
all transactions. 

2.  Wait until SHOW ENGINE INNODB STATUS
http://dev.mysql.com/doc/refman/5.5/en/show-engine.html  shows that
there are no active transactions in the database, and the main thread
status of InnoDB is Waiting for server activity. Then you can make a
copy of the .ibd file. 

 

 I would assume that flush tables with read lock would work 
 for 1. and then you wait for 2. to happen. Probably shouldn't 
 take very long, especially in the quiet moments.
 
 
 
Can anyone confirm that FLUSH TABLES WITH READ LOCK is sufficient to
quiesce the InnoDB background threads?  When Googling this, I'm seeing
posts saying that even after a flush  lock, InnoDB keeps making changes
to certain files (metadata?) and that's why it is never really safe
(according to them) to copy the files from a running instance of MySQL.
Call me persistent (or just annoyingly thick-headed) but I am not fully
satisfied their explanations.
 
 
--Eric
 
 


Disclaimer - January 26, 2011 
This email and any files transmitted with it are confidential and intended 
solely for Johan De Meersman,Shawn Green (MySQL),Reindl 
Harald,mysql@lists.mysql.com. If you are not the named addressee you should not 
disseminate, distribute, copy or alter this email. Any views or opinions 
presented in this email are solely those of the author and might not represent 
those of Physicians' Managed Care or Physician Select Management. Warning: 
Although Physicians' Managed Care or Physician Select Management has taken 
reasonable precautions to ensure no viruses are present in this email, the 
company cannot accept responsibility for any loss or damage arising from the 
use of this email or attachments. 
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/


[ANN] ODB C++ ORM 1.1.0 released

2011-01-26 Thread Boris Kolpackov
Hi,

I am pleased to announce the release of ODB 1.1.0.

ODB is an open-source object-relational mapping (ORM) system for C++. It
allows you to persist C++ objects to a relational database without having
to deal with tables, columns, or SQL and without manually writing any of
the mapping code. 

Major new features in this release:

  * Support for storing containers in the database, for example:

#pragma db object
class person
{
  ...

  std::setstd::string emails_;
};

  * Support for unidirectional and bidirectional object relationships, 
including lazy loading. For example:

#pragma db object
class employer
{
  ...

  #pragma db inverse(employer_)
  std::vectorlazy_weak_ptremployee  employees_;
};

#pragma db object
class employee
{
  ...

  shared_ptremployer employer_;
};

  * Support for composite value types, for example:

#pragma db value
class name
{
  ...

  std::string first_;
  std::string last_;
};

#pragma db object
class person
{
  ...

  name name_;
};

  * Support for optional object cache (session).

  * Support for native SQL statement execution.

  * Support for customization of object pointers that allows you to
use smart pointers to return, pass, and cache persistent objects.

A more detailed discussion of the major new features can be found in
the following blog post:

http://www.codesynthesis.com/~boris/blog/2011/01/26/odb-1-1-0-released/

For the complete list of new features in this version see the official
release announcement:

http://www.codesynthesis.com/pipermail/odb-announcements/2011/01.html

ODB is written in portable C++ and you should be able to use it with any
modern C++ compiler. In particular, we have tested this release on GNU/Linux
(x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC)
with GNU g++ 4.2.x-4.5.x, MS Visual C++ 2008 and 2010, and Sun Studio 12.

More information, documentation, source code, and pre-compiled binaries are
available from:

http://www.codesynthesis.com/products/odb/

Enjoy,
Boris


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org



Data in Table Is Different When Seen From Different Sources

2011-01-26 Thread Hal Vaughan
I'm having the strangest issue.  I am using a Perl program to test out some 
other Perl programs and all the Perl connections with MySQL are normal, as in 
I use the standard interface.  But in the test program I'm just using this:

$out = `mysql --table -eSELECT * FROM search.Status`;
print $out\n;

as a quick and dirty way to check on the data tables while I'm working.  This 
test program gives this output:

+++---+---+--++-+--+---+
| Source | Search | Stage | Status| Resource | TotalItems | CurrentItem | 
CheckIn  | PID   |
+++---+---+--++-+--+---+
| alpha  | one| 3 | waiting   |1 | -1 |  -1 | 
2011-0126-160720 | 0 | 
| alpha  | two| 1 | searching |  201 | -1 |  -1 | 
2011-0126-160115 | 12331 | 
+++---+---+--++-+--+---+

I have two items in the first row that are my concern, the first is in the 
column Status, the 2nd is in the column PID.  These are updated.  Also, this 
program is a loop and after it displayed this table, I locked the screen with 
ctrl-q (in a BASH shell using Konsole on OS X with MacPorts).  (Also, this 
system is a VM, under parallels, on another Mac and I'm using ssh to connect to 
that system to run all these commands.)

But when I go to the console where I've logged into MySQL and display this 
table, I get:

mysql SELECT * FROM search.Status;
+++---+---+--++-+--+---+
| Source | Search | Stage | Status| Resource | TotalItems | CurrentItem | 
CheckIn  | PID   |
+++---+---+--++-+--+---+
| alpha  | one| 3 | searching |1 | -1 |  -1 | 
2011-0126-160120 | 12336 | 
| alpha  | two| 1 | searching |  201 | -1 |  -1 | 
2011-0126-160115 | 12331 | 
+++---+---+--++-+--+---+
2 rows in set (0.00 sec)

When I go to a command line and cut and paste the command from in the program, 
I get this:

hal@tnet-search:threshNet]$ mysql --table -eSELECT * FROM search.Status
+++---+---+--++-+--+---+
| Source | Search | Stage | Status| Resource | TotalItems | CurrentItem | 
CheckIn  | PID   |
+++---+---+--++-+--+---+
| alpha  | one| 3 | searching |1 | -1 |  -1 | 
2011-0126-155546 | 12294 | 
| alpha  | two| 1 | searching |  201 | -1 |  -1 | 
2011-0126-155545 | 12289 | 
+++---+---+--++-+--+---+


So I'm checking this data table from THREE sources, from within MySQL, from the 
command line, and from within the Perl program.  How can I get different values 
in two cells in the table?

Is there some kind of buffering along the way that could effect the output to 
the Perl program?


Thanks for any ideas on this!



Hal
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org



Re: Data in Table Is Different When Seen From Different Sources

2011-01-26 Thread misiaq
Hal Vaughan h...@halblog.com wrote:
 I'm having the strangest issue.  I am using a Perl program to test out some 
 other Perl programs and all the Perl connections with MySQL are normal, as 
 in I use the standard interface.  But in the test program I'm just using this:
 
[... cut ...]

Transaction isolation level? 
Add a timestamp column showing last update and then compare values.

Regards,
m

-

Sprawdz pogode.
Kliknij  http://linkint.pl/f2903


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org



Re: Data in Table Is Different When Seen From Different Sources

2011-01-26 Thread Hal Vaughan

On Jan 26, 2011, at 5:11 PM, mis...@poczta.fm wrote:

 Hal Vaughan h...@halblog.com wrote:
 I'm having the strangest issue.  I am using a Perl program to test out some 
 other Perl programs and all the Perl connections with MySQL are normal, as 
 in I use the standard interface.  But in the test program I'm just using 
 this:
 
 [... cut ...]
 
 Transaction isolation level? 
 Add a timestamp column showing last update and then compare values.

Thanks, actually, after sending that, I put in more time fields (since I would 
need them anyway) and that led me to finally finding a rogue process that was 
being forked in Perl, and finishing up fast enough that I didn't see it when I 
tried ps -ax.

So it's solved now -- rogue process.


Thanks!



Hal
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org