Migration generates timestamps that are too high for inactive tables #4668

Closed
danielmewes opened this Issue Aug 11, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@danielmewes
Member

danielmewes commented Aug 11, 2015

The timestamp is set to 9223372036854775808.
The effect this has is that if you add a new replica to a table after migration, that replica will never come up because its timestamp is always going to be higher than any other timestamp.

There might be a second problem here that inactive tables do not synchronize their states correctly.

Once this is fixed, we're going to ship a 2.1.1 point release asap.

@danielmewes danielmewes added this to the 2.1.x milestone Aug 11, 2015

@Tryneus

This comment has been minimized.

Show comment
Hide comment
@Tryneus

Tryneus Aug 12, 2015

Member

Workaround for the invalid timestamp is up in review 3146. We still need to handle the case of an inactive replica having a higher timestamp than all active replicas in the cluster. Also, we should create an issue to remove the workaround (and rewrite all invalid timestamps in the metadata) in v2.2.x.

Member

Tryneus commented Aug 12, 2015

Workaround for the invalid timestamp is up in review 3146. We still need to handle the case of an inactive replica having a higher timestamp than all active replicas in the cluster. Also, we should create an issue to remove the workaround (and rewrite all invalid timestamps in the metadata) in v2.2.x.

@Tryneus

This comment has been minimized.

Show comment
Hide comment
@Tryneus

Tryneus Aug 12, 2015

Member

The workaround for the invalid timestamp has been approved and merged into next in commit 1b1efa9, and cherry-picked into v2.1.x in commit bd785e8. Will be in release 2.1.1.

Member

Tryneus commented Aug 12, 2015

The workaround for the invalid timestamp has been approved and merged into next in commit 1b1efa9, and cherry-picked into v2.1.x in commit bd785e8. Will be in release 2.1.1.

@danielmewes danielmewes modified the milestones: 2.1.x, 2.1.1 Aug 12, 2015

danielmewes added a commit that referenced this issue Aug 12, 2015

danielmewes added a commit that referenced this issue Aug 12, 2015

@danielmewes

This comment has been minimized.

Show comment
Hide comment
@danielmewes

danielmewes Aug 12, 2015

Member

A second work-around to handle the case of an inactive server having a higher timestamp is now in next 678f880 and in v2.1.x df27878. The code review for this was 3148.

This solution is temporary as well, but a cleaner solution is considerably more work and needs additional though. We will probably replace that code by a different logic in 2.2.

Member

danielmewes commented Aug 12, 2015

A second work-around to handle the case of an inactive server having a higher timestamp is now in next 678f880 and in v2.1.x df27878. The code review for this was 3148.

This solution is temporary as well, but a cleaner solution is considerably more work and needs additional though. We will probably replace that code by a different logic in 2.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment