Thanks! I'm away from home I will take a look on that when coming back at
the beginning of next week.

Le ven. 29 mai 2015 03:48, Bartek Ogryczak notifications@github.com a
écrit :

The rationale behind this is that as server fails over, the binlog
position you've got stored from failed server might no longer be valid on
the new one. With MySQL 5.6 you're fine, because you got GTIDs, but if
you're using older MySQL there is no way of telling from which log position
you should start. Timestamp helps to roughly know where to start. If

your app is capable of dealing with duplicates, that is good enough.

You can view, comment on, or merge this pull request online at:

#114
Commit Summary

• Adding support for skipping the binlog until reaching specified
  timestamp.

File Changes

• M pymysqlreplication/binlogstream.py
  https://github.com/noplay/python-mysql-replication/pull/114/files#diff-0
  (7)
• M pymysqlreplication/tests/test_basic.py
  https://github.com/noplay/python-mysql-replication/pull/114/files#diff-1
  (20)

Patch Links:

• https://github.com/noplay/python-mysql-replication/pull/114.patch
• https://github.com/noplay/python-mysql-replication/pull/114.diff

—
Reply to this email directly or view it on GitHub
#114.

Why not implement that just in the application itself?

I think it's usefull if you changed the schema and want to skip the events.

@bjoernhaeuser the reason for doing here and not at application level is to avoid inflating rows into Python objects, which is CPU consuming and seriously limits the throughput.

MySQL's binlog reader has similar option: https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_start-datetime

sorry about this back and forth with tests, but the outcome seems to depend heavily on MySQL version and configuration :-/

FYI, I've squashed the unittest commit mess.

Thanks