This message was deleted.
# k3sa
adamant-kite-43734
09/26/2022, 5:30 AMThis message was deleted.
c
creamy-pencil-82913
09/26/2022, 5:45 AMI have honestly never seen that happen. Unless there is something wrong with the database, K3s should be able to run for years before you get anywhere near hitting sqlite’s maximum integer value for the ID field. You could try doing
ALTER TABLE kine CHANGE id id BIGINT NOT NULL AUTO_INCREMENTl
limited-potato-16824
09/26/2022, 5:49 AMThis cluster have been up and running for 18 months and have ~200 nodes.
I was thinking of changing id to BIGINT but realized that this might break stuff.
I'll create a issue in the k3s repo
c
creamy-pencil-82913
09/26/2022, 5:52 AMHmm. 200 nodes is definitely on the larger side for a k3s cluster. More important is going to be the churn rate on cluster resources though, which will depend on what you have deployed to it and how much it actually stores in kubernetes vs just being orchestrated by it. What version of K3s are you currently on?
l
limited-potato-16824
09/26/2022, 5:57 AMWe are still on v1.22.12+k3s1
limited-potato-16824
09/26/2022, 6:10 AMlimited-potato-16824
09/26/2022, 6:13 AMDeployments to the cluster is done with Rancher Fleet, and we do deployments several times per day. Fleet deployments do create a lot of secrets that is stored in the database, we have set a history limit to 2 for all Fleet deployments.
limited-potato-16824
09/26/2022, 6:16 AMWe have other deployments as well, where the largest one have 409 clients so I guess will will run into this issue there as well.
limited-potato-16824
09/26/2022, 6:47 AM@creamy-pencil-82913 if we try to change the int for id, we would need to change the other int's as well in the table right?
I'm not very savvy with SQL
limited-potato-16824
09/26/2022, 10:35 AMFYI, we dropped the indexes and did a alter table and now using bigint
109 Views