TokuDB table stats row count decreases to 1
I have a few Percona 5.6.30 servers with a TokuDB table that has ~120 million rows. On some of these servers, row count in SHOW TABLE STATUS
mysteriously decreases until is hits 1. This is accompanied by rather unpleasant performance reduction and happens on both master and slave servers.
I've tried to fix this by running ANALYZE TABLE
, running OPTIMIZE TABLE
, restarting the affected server, running ALTER TABLE ... FORCE
. None of these has had any effect. The only two things that help are ALTER TABLE ... ENGINE=TokuDB
and recreating the table from dumped data. These bring row count back to sane values, after which they begin to decrease again.
Any hints about what might have caused this issue and how to fix it would be helpful.
percona-server tokudb
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I have a few Percona 5.6.30 servers with a TokuDB table that has ~120 million rows. On some of these servers, row count in SHOW TABLE STATUS
mysteriously decreases until is hits 1. This is accompanied by rather unpleasant performance reduction and happens on both master and slave servers.
I've tried to fix this by running ANALYZE TABLE
, running OPTIMIZE TABLE
, restarting the affected server, running ALTER TABLE ... FORCE
. None of these has had any effect. The only two things that help are ALTER TABLE ... ENGINE=TokuDB
and recreating the table from dumped data. These bring row count back to sane values, after which they begin to decrease again.
Any hints about what might have caused this issue and how to fix it would be helpful.
percona-server tokudb
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I have a few Percona 5.6.30 servers with a TokuDB table that has ~120 million rows. On some of these servers, row count in SHOW TABLE STATUS
mysteriously decreases until is hits 1. This is accompanied by rather unpleasant performance reduction and happens on both master and slave servers.
I've tried to fix this by running ANALYZE TABLE
, running OPTIMIZE TABLE
, restarting the affected server, running ALTER TABLE ... FORCE
. None of these has had any effect. The only two things that help are ALTER TABLE ... ENGINE=TokuDB
and recreating the table from dumped data. These bring row count back to sane values, after which they begin to decrease again.
Any hints about what might have caused this issue and how to fix it would be helpful.
percona-server tokudb
I have a few Percona 5.6.30 servers with a TokuDB table that has ~120 million rows. On some of these servers, row count in SHOW TABLE STATUS
mysteriously decreases until is hits 1. This is accompanied by rather unpleasant performance reduction and happens on both master and slave servers.
I've tried to fix this by running ANALYZE TABLE
, running OPTIMIZE TABLE
, restarting the affected server, running ALTER TABLE ... FORCE
. None of these has had any effect. The only two things that help are ALTER TABLE ... ENGINE=TokuDB
and recreating the table from dumped data. These bring row count back to sane values, after which they begin to decrease again.
Any hints about what might have caused this issue and how to fix it would be helpful.
percona-server tokudb
percona-server tokudb
edited Jun 7 '16 at 21:15
che
asked May 25 '16 at 20:32
cheche
1113
1113
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
We looked into it for a while and it looks like this is a regression in Percona. I wasn't yet able to reproduce it outside our own environment, but it started when we upgraded our servers from 5.6.22 to 5.6.28, persisted through upgrading to 5.6.30, and disappeared when we returned to 5.6.22.
The stats decreate was present on both master and slave servers and apparently depended on traffic the database served. I was not able to replicate this on any smaller data nor with any specific queries.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f139552%2ftokudb-table-stats-row-count-decreases-to-1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
We looked into it for a while and it looks like this is a regression in Percona. I wasn't yet able to reproduce it outside our own environment, but it started when we upgraded our servers from 5.6.22 to 5.6.28, persisted through upgrading to 5.6.30, and disappeared when we returned to 5.6.22.
The stats decreate was present on both master and slave servers and apparently depended on traffic the database served. I was not able to replicate this on any smaller data nor with any specific queries.
add a comment |
We looked into it for a while and it looks like this is a regression in Percona. I wasn't yet able to reproduce it outside our own environment, but it started when we upgraded our servers from 5.6.22 to 5.6.28, persisted through upgrading to 5.6.30, and disappeared when we returned to 5.6.22.
The stats decreate was present on both master and slave servers and apparently depended on traffic the database served. I was not able to replicate this on any smaller data nor with any specific queries.
add a comment |
We looked into it for a while and it looks like this is a regression in Percona. I wasn't yet able to reproduce it outside our own environment, but it started when we upgraded our servers from 5.6.22 to 5.6.28, persisted through upgrading to 5.6.30, and disappeared when we returned to 5.6.22.
The stats decreate was present on both master and slave servers and apparently depended on traffic the database served. I was not able to replicate this on any smaller data nor with any specific queries.
We looked into it for a while and it looks like this is a regression in Percona. I wasn't yet able to reproduce it outside our own environment, but it started when we upgraded our servers from 5.6.22 to 5.6.28, persisted through upgrading to 5.6.30, and disappeared when we returned to 5.6.22.
The stats decreate was present on both master and slave servers and apparently depended on traffic the database served. I was not able to replicate this on any smaller data nor with any specific queries.
answered Jun 21 '16 at 13:00
cheche
1113
1113
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f139552%2ftokudb-table-stats-row-count-decreases-to-1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown