WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => Modules => Topic started by: sky writer on January 27, 2018, 03:48:59 PM
-
I backed up a live site and when I tried to import the database into WB Portable phpmyadmin, there was an "excessive file size" error. The database sql file was over 7Mb
I changed the setting in WBportable/settings/php.ini to upload_max_filesize = 10M to allow the import. The import succeeded. Then I noticed that the croncheck table was over 5MiB
This site is quite large, with thousands of image files. I know you warned that this table could get large. Do you have any suggestions on how to keep this database size manageable? Is it safe to just delete the croncheck table from time to time, when it gets too large?
-
Ich arbeite auch mit Croncheck und es gibt immer nur 5 Einträge in der Tabelle, der neue Eintrag überschreibt den ältesten. Somit ist die "Größe" relativ stabil.Bei mir aber auch ca. 4MB
google tranclate
I also work with croncheck and there are always only 5 entries in the table, the new entry overwrites the oldest one. Thus, the "size" is relatively stable. But I also about 4MB
-
the old version of croncheck add record by record, the newer version has a limiter, but it's no problem, to delete records there in your database.
in worst case, the script add any records again, but only the latest
to the sql's - you can use also a single zip (with only one sql inside) or a zip with a lot of sql's inside (maybe table by table)
and also a gz-File to upload your backup
P.S. 7mb is a small file ;-)
-
I also work with croncheck and there are always only 5 entries in the table, the new entry overwrites the oldest one. Thus, the "size" is relatively stable. But I also about 4MB
Yes, there are only five rows in my table as well, but the data is over one million (1,000,000) characters in each. Like I said, this is a VERY large, content heavy, site. I am not suggesting that something is wrong with the croncheck script, I was just looking for direction on a possible method to lower the site. But, if this is just the reality of having a content-heavy site, then, that is just fine.
the old version of croncheck add record by record, the newer version has a limiter, but it's no problem, to delete records there in your database.
in worst case, the script add any records again, but only the latest
to the sql's - you can use also a single zip (with only one sql inside) or a zip with a lot of sql's inside (maybe table by table)
and also a gz-File to upload your backup
P.S. 7mb is a small file ;)
I have the latest version (v3) of the script installed. I was not suggesting that a 7mb file was huge, it is just an issue when the default "upload_max_filesize" is set to 2M in WBportable. Like I said, I made the change to the php.ini file and was able to proceed. I will delete the table and see if the newly created table brings the size down.
Anyway, thanks for your time.
-
I deleted the table, and the next cron run added the table back, with an entry with a size of 2.3MiB. Made a couple changes, and the next cron run the file was up to 3.5MiB. So, it is on track to becoming relatively close to what it was again. Not a problem. Just wanted to make sure this was not some kind of problem with the script. I'll likely just dump the croncheck table before doing future backup exports.
-
croncheck read all the files on this domain and compare it with different methods with the last report from the database. if you dont have a report there, it add's every file with link, date of the last changes, md5-checksum etc
in the next job, it add nothing, if you change nothing.
but if you add a (new) addon or other files or if you change the informations about the files on this domain (simple opening and save it's enough), the script register this new informations and add this file(s) at you last changes in the next report.
it makes no sense for me, to work with the croncheck on a local domain, where you maybe develop or test a lot of things. WBPortable has also no CronJob-function, so you have to start is manually
-
it makes no sense for me, to work with the croncheck on a local domain, where you maybe develop or test a lot of things. WBPortable has also no CronJob-function, so you have to start is manually
I'm not working with croncheck locally. I simply received an error "excessive size" when I tried to import the database backup from a live server site into WB Portable, and upon investigation, I found that the croncheck table was the reason the database file was so large.
I checked a bunch of other live sites, and the croncheck tables are all around 2MiB. So, when this one was 5MiB, I thought there might possibly be an issue. But as I have stated, this site has thousands of images and displays them using bakery (so there are thumbnails, and all other associated pages), so I know assume it is just a consequence of this sites content that makes the croncheck table larger than others.
Thanks again.