Google CloudSQL instance storage is growing out of control
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have encountered an issue with Ggoole Cloud SQL (2nd gen).
For some reason after a while, the database went from 20GB to 64GB in a matter of hours. It used to climb from 20 to 25 then purge as entries were added and removed over time.
Nothing happened on the server connecting to the database, and I have Cloud SQL flags set to off. Any ideas what else I can try?
google-cloud-platform google-cloud-sql
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
add a comment |
I have encountered an issue with Ggoole Cloud SQL (2nd gen).
For some reason after a while, the database went from 20GB to 64GB in a matter of hours. It used to climb from 20 to 25 then purge as entries were added and removed over time.
Nothing happened on the server connecting to the database, and I have Cloud SQL flags set to off. Any ideas what else I can try?
google-cloud-platform google-cloud-sql
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
Is binary logging enabled? cloud.google.com/sql/docs/mysql/backup-recovery/…
– LundinCast
Nov 25 '18 at 11:49
@LundinCast, yes it is. The database itself is 1.4 GB, no major changes made. Could binary logging cause it to blow up by 400% like this? Looking at the history there, it was increasing increasing then purging and so on. I had that same pattern with a steady increase for over a year on this DB with no issues.
– Adrian
Nov 25 '18 at 21:39
add a comment |
I have encountered an issue with Ggoole Cloud SQL (2nd gen).
For some reason after a while, the database went from 20GB to 64GB in a matter of hours. It used to climb from 20 to 25 then purge as entries were added and removed over time.
Nothing happened on the server connecting to the database, and I have Cloud SQL flags set to off. Any ideas what else I can try?
google-cloud-platform google-cloud-sql
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
I have encountered an issue with Ggoole Cloud SQL (2nd gen).
For some reason after a while, the database went from 20GB to 64GB in a matter of hours. It used to climb from 20 to 25 then purge as entries were added and removed over time.
Nothing happened on the server connecting to the database, and I have Cloud SQL flags set to off. Any ideas what else I can try?
google-cloud-platform google-cloud-sql
google-cloud-platform google-cloud-sql
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
edited Nov 26 '18 at 10:18
LundinCast
2,91241526
2,91241526
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
asked Nov 25 '18 at 5:11
AdrianAdrian
11318
11318
Is binary logging enabled? cloud.google.com/sql/docs/mysql/backup-recovery/…
– LundinCast
Nov 25 '18 at 11:49
@LundinCast, yes it is. The database itself is 1.4 GB, no major changes made. Could binary logging cause it to blow up by 400% like this? Looking at the history there, it was increasing increasing then purging and so on. I had that same pattern with a steady increase for over a year on this DB with no issues.
– Adrian
Nov 25 '18 at 21:39
add a comment |
Is binary logging enabled? cloud.google.com/sql/docs/mysql/backup-recovery/…
– LundinCast
Nov 25 '18 at 11:49
@LundinCast, yes it is. The database itself is 1.4 GB, no major changes made. Could binary logging cause it to blow up by 400% like this? Looking at the history there, it was increasing increasing then purging and so on. I had that same pattern with a steady increase for over a year on this DB with no issues.
– Adrian
Nov 25 '18 at 21:39
Is binary logging enabled? cloud.google.com/sql/docs/mysql/backup-recovery/…
– LundinCast
Nov 25 '18 at 11:49
Is binary logging enabled? cloud.google.com/sql/docs/mysql/backup-recovery/…
– LundinCast
Nov 25 '18 at 11:49
@LundinCast, yes it is. The database itself is 1.4 GB, no major changes made. Could binary logging cause it to blow up by 400% like this? Looking at the history there, it was increasing increasing then purging and so on. I had that same pattern with a steady increase for over a year on this DB with no issues.
– Adrian
Nov 25 '18 at 21:39
@LundinCast, yes it is. The database itself is 1.4 GB, no major changes made. Could binary logging cause it to blow up by 400% like this? Looking at the history there, it was increasing increasing then purging and so on. I had that same pattern with a steady increase for over a year on this DB with no issues.
– Adrian
Nov 25 '18 at 21:39
add a comment |
1 Answer
1
active
oldest
votes
This is most likely due to binary logs. When they are enabled, MySQL will make a record of all changes, which is required for replication or point-in-time recovery. This means that the growth of binary logs is roughly proportional to the amount of modified rows (even if these rows were actually deleted and db total size reduced).
Note that they will not grow indefinitely. Binary logs older than the oldest automatic backup (7 days) are purged automatically.
Also note that storage size can be increased (I believe you have automatic storage increase enabled) but it cannot be decreased, as documented here. This means that when binary logs are purged, free disk space will increase but the total storage size will remain identical. If you want to reduce your disk size after binlogs are purged, you can follow the suggested method here.
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fstackoverflow.com%2fquestions%2f53464839%2fgoogle-cloudsql-instance-storage-is-growing-out-of-control%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
This is most likely due to binary logs. When they are enabled, MySQL will make a record of all changes, which is required for replication or point-in-time recovery. This means that the growth of binary logs is roughly proportional to the amount of modified rows (even if these rows were actually deleted and db total size reduced).
Note that they will not grow indefinitely. Binary logs older than the oldest automatic backup (7 days) are purged automatically.
Also note that storage size can be increased (I believe you have automatic storage increase enabled) but it cannot be decreased, as documented here. This means that when binary logs are purged, free disk space will increase but the total storage size will remain identical. If you want to reduce your disk size after binlogs are purged, you can follow the suggested method here.
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
add a comment |
This is most likely due to binary logs. When they are enabled, MySQL will make a record of all changes, which is required for replication or point-in-time recovery. This means that the growth of binary logs is roughly proportional to the amount of modified rows (even if these rows were actually deleted and db total size reduced).
Note that they will not grow indefinitely. Binary logs older than the oldest automatic backup (7 days) are purged automatically.
Also note that storage size can be increased (I believe you have automatic storage increase enabled) but it cannot be decreased, as documented here. This means that when binary logs are purged, free disk space will increase but the total storage size will remain identical. If you want to reduce your disk size after binlogs are purged, you can follow the suggested method here.
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
add a comment |
This is most likely due to binary logs. When they are enabled, MySQL will make a record of all changes, which is required for replication or point-in-time recovery. This means that the growth of binary logs is roughly proportional to the amount of modified rows (even if these rows were actually deleted and db total size reduced).
Note that they will not grow indefinitely. Binary logs older than the oldest automatic backup (7 days) are purged automatically.
Also note that storage size can be increased (I believe you have automatic storage increase enabled) but it cannot be decreased, as documented here. This means that when binary logs are purged, free disk space will increase but the total storage size will remain identical. If you want to reduce your disk size after binlogs are purged, you can follow the suggested method here.
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
This is most likely due to binary logs. When they are enabled, MySQL will make a record of all changes, which is required for replication or point-in-time recovery. This means that the growth of binary logs is roughly proportional to the amount of modified rows (even if these rows were actually deleted and db total size reduced).
Note that they will not grow indefinitely. Binary logs older than the oldest automatic backup (7 days) are purged automatically.
Also note that storage size can be increased (I believe you have automatic storage increase enabled) but it cannot be decreased, as documented here. This means that when binary logs are purged, free disk space will increase but the total storage size will remain identical. If you want to reduce your disk size after binlogs are purged, you can follow the suggested method here.
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
answered Nov 26 '18 at 10:44
LundinCastLundinCast
2,91241526
2,91241526
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
add a comment |
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
with binary logging, the usage never went down, and I have backups every morning. After turning them off however, the size went back down to where it was before. As a solution to my particular issue, I moved the database (1.4 GB) to a new server where I made sure binary logging was off from the start. The size of that server now hovers around 4-5 GB. The original question remains however: With the connected server not showing any irregular activities meaning not a lot of changes to the DB, how would binary logs get this out of control all on their own? Could something else be involved?
– Adrian
Nov 26 '18 at 14:25
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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%2fstackoverflow.com%2fquestions%2f53464839%2fgoogle-cloudsql-instance-storage-is-growing-out-of-control%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
Is binary logging enabled? cloud.google.com/sql/docs/mysql/backup-recovery/…
– LundinCast
Nov 25 '18 at 11:49
@LundinCast, yes it is. The database itself is 1.4 GB, no major changes made. Could binary logging cause it to blow up by 400% like this? Looking at the history there, it was increasing increasing then purging and so on. I had that same pattern with a steady increase for over a year on this DB with no issues.
– Adrian
Nov 25 '18 at 21:39