MariaDB binay logs growing more than 1GB per hour after upgrading to Build 240420-ef5f14bc4 #4226
Comments
|
You can format the error log by adding ``` before and after the text. And/or hide the long logs by using a section: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-collapsed-sections |
|
@cvinhaes see https://mariadb.com/kb/en/using-and-maintaining-the-binary-log/ for how to limit the binary log size Reading your issue description, it is not entirely clear if you use the default MariaDB image and configuration we provide with our Docker Compose example file(s) or if you run a custom MariaDB server? |
lastzero
added
technical-support
|
Thank you for your reply. I run my own setup of MariaBD, the compose file is provided herein. Now, my point is that the exact same configuration for the DB was not generating such amount of logs when using the Nov-28th version of photoprism. The binary log should not be the problem because it's been in used with this same DB configuration for quite some time and the default 30 days rotation was more than enough to contain it until upgrading Photoprism few days ago. From the logs, it seems to me that some faces-related operation is in loop or is generating way more transactions than the previous version of Photoprism. The only change to the environment was the upgrade of Photoprism from Nov-28th to Apr-20th , which was done by redeploying the container with the new image. BTW, I have upgraded Photoprism many other times by following this exact same process with no issues until now. Would you say that there is a way to understand what Photoprism is doing with faces and if there's a backlog to be processed? Compose file for the database... |
|
I'm not aware of any faces related changes in our latest release. It could simply be that some data changed, like you assigned different names for the same face. Might be a typo? We already have an issue for improving the face recognition in general, see our public roadmap. |
Hi!
After updating to Build 240420-ef5f14bc4 the space in my disk disappeared really fast. Searching for the culprit I found that mariadb binary logs are growing more that 1GB per hour. Looking into the logs I find that updates to marker_uid are causing most of the load. I can tell that Photoprism is actually updating faces from the Photoprism log, but I don't understand what is causing so much activity without changes to the files and it's now very hard to keep Photoprism running because of this issue.
1. What is not working as documented?
MariaDB bin logs are growing at more that 1GB per hour until filling the disk.
2. How can we reproduce it?
As soon as I start the service.
I'm using the standard docker image with Docker version 23.0.1, build a5ee5b1 on Linux 6.0.0-0.deb11.6-amd64 x86_64.
Database is MariaDB Server 1:10.9.3+maria~ubu2204. Photos are stores in a folder structure pointed as the originals for Photoprism in the composer file. This setup has worked flawless for over one year until now.
Here is a tail on the logs for Photoprism...
And here is an extract of a transaction from the log. This is what the transactions look like...
The text was updated successfully, but these errors were encountered: