Am 01.04.2016 um 21:09 schrieb Lentes, Bernd:
- Am 1. Apr 2016 um 17:45 schrieb shawn l.green shawn.l.gr...@oracle.com:
You said, "This is done on the master, written in the log and then
replicated to the slave, "
The INSERT would not appear in the Binary log until after session 1
Sorry for pm !
- Am 1. Apr 2016 um 17:45 schrieb shawn l.green shawn.l.gr...@oracle.com:
>>> You would be better served by first converting your MyISAM tables to
>>> InnoDB to stop mixing storage engine behaviors (transactional and
>>> non-transactional) within the scope of a single
- Am 1. Apr 2016 um 17:52 schrieb shawn l.green shawn.l.gr...@oracle.com:
>> What is true ? when the transaction started or when the first read is
>> performed ?
> Until you need to establish a snapshot of the data, then you don't need
> a snapshot position.
>
> The transaction
On 4/1/2016 10:08 AM, Lentes, Bernd wrote:
- On Apr 1, 2016, at 3:12 PM, Bernd Lentes
bernd.len...@helmholtz-muenchen.de wrote:
Btw:
i read about isolation levels. REPEATABLE READ is the default for InnoDB.
http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_repeatable_read says:
On 4/1/2016 9:12 AM, Lentes, Bernd wrote:
- On Mar 25, 2016, at 9:54 PM, shawn l.green shawn.l.gr...@oracle.com wrote:
"Unsafe" in that sense replies to the fact that certain commands can
have a different effect when processed from the Binary Log than they did
when they were executed
- On Apr 1, 2016, at 3:12 PM, Bernd Lentes
bernd.len...@helmholtz-muenchen.de wrote:
Btw:
i read about isolation levels. REPEATABLE READ is the default for InnoDB.
http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_repeatable_read says:
"...so that all queries within a transaction
- On Mar 25, 2016, at 9:54 PM, shawn l.green shawn.l.gr...@oracle.com wrote:
> "Unsafe" in that sense replies to the fact that certain commands can
> have a different effect when processed from the Binary Log than they did
> when they were executed originally on the system that wrote the
