-
Notifications
You must be signed in to change notification settings - Fork 683
Replaying binlog with dropped columns causes unhandled exception. #118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
vartec
pushed a commit
to vartec/python-mysql-replication
that referenced
this issue
Jun 19, 2015
…lien-duponchelle#117 does not fix that one
vartec
pushed a commit
to vartec/python-mysql-replication
that referenced
this issue
Jun 19, 2015
…lien-duponchelle#117 does not fix that one
vartec
pushed a commit
to vartec/python-mysql-replication
that referenced
this issue
Jun 19, 2015
…lien-duponchelle#117 does not fix that one
vartec
pushed a commit
to vartec/python-mysql-replication
that referenced
this issue
Jun 19, 2015
…lien-duponchelle#117 does not fix that one
Created a unittest to show another scenario when it is still a problem. 9549d6e |
vartec
pushed a commit
to vartec/python-mysql-replication
that referenced
this issue
Jun 20, 2015
…lien-duponchelle#117 does not fix that one
Are there any updates on this? This is a critical issue we are experiencing as well when using the stitchdata.com MySQL tap which uses this library for binlog replication |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce:
pymysqlreplication
replaying the binlog from the position prior to dropping the columnER:
Working fine.
AR:
Unhandled error:
This is partially solved by 4c48538, but that doesn't solve the deeper issue at hand which is how the schema for tables is obtained. Schema is always obtained from the current version of
information_schema
no matter how far in the past the RowEvent processed is.The text was updated successfully, but these errors were encountered: