Skip to content
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

Increase size of 'value' column in sys.operator table #447

Merged
merged 1 commit into from
Jan 8, 2020

Conversation

vitobotta
Copy link
Contributor

Hi, as discussed on Slack this increases the size of the value column of the sys.operator table.
Thanks!

@AMecea AMecea merged commit 190947d into bitpoke:master Jan 8, 2020
@eik3
Copy link
Contributor

eik3 commented Jan 9, 2020

I'm interested in understanding the problem that's being tackled here - I had a look at #mysql-operator in the Kubernetes Slack but didn't find the discussion.
Would you mind sharing where we can find the discussion or describe the problem with the value column size?

@AMecea
Copy link
Contributor

AMecea commented Jan 9, 2020

Hi @eik3 ,

Long story short, xtrabackup tool can write a PURGE_GTID longer than 256 characters, see the example below.

For example, a value that overflows a varchar(256).

REPLACE INTO sys_operator.status VALUES ('backup_gtid_purged', '11e5285c-2bb0-11ea-a652-c691ce6e5474:1-176182,215fc1da-2d4b-11ea-b76b-16cb551023a2:1-126,221995c5-2fcf-11ea-92c0-56336a6d6b9f:1-109947,2ed660d8-16c7-11ea-b5e0-9ee33242215a:1-1740694,44aa9c3a-2968-11ea-98f2-e2c8070b618f:1-9466,4892323d-289b-11ea-a3cb-66a14998e5d8:1-59643,79830932-2991-11ea-9de7-a22c2fff612c:1-105173,886b5fe6-0a2b-11ea-b4a2-1e569d296ed3:1-407421,a6a57e6e-2721-11ea-b52b-3a220c4f6ab0:1-104395,ba326e47-0dfc-11ea-9b67-6ad8f55f6ea5:1-245303,cdf9403c-2a88-11ea-80f9-dac0a15d95ce:1-64009,dd8a762c-1395-11ea-8650-726faff0e1df:1-323914,ec2a2236-103f-11ea-bd78-8e12c0794c17:1-361459');

The following query will fail with [ERROR] 1406 Data too long for column 'value' at row 1 and queries before him will not be executed. This will result in a bad cluster configuration, usually with errors like CoMaster in orchestrator when restoring a cluster from a backup or Duplicate entry '458' for key 'PRIMARY'.

The related issue is #446 but is not updated.

The discussion was private on slack, sorry.

@vitobotta
Copy link
Contributor Author

Hi guys,

sorry @eik3 I should have added some info... but @AMecea explained it better than I would.

@AMecea I just restored my cluster using the 0.3.6 tag and all looks good 👍
No more errors when setting up the first replica nor the additional replicas, and the replication works just fine. Thanks!

@eik3
Copy link
Contributor

eik3 commented Jan 10, 2020

Thanks @AMecea for the great explanation, makes sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants