Goal: I am trying to move the postgres db from kubernetes to AWS RDS
Steps so far: I did a pg_dump of the db in kubernetes then restored it to RDS. I then re-deployed Sonar with settings to use the remote db. When going to sonar there are no projects or rules or anything from the old db. I created a new project and checked the RDS db and confirmed it is there, so Sonar is connected to the RDS db, it just does not read in what was imported.
I expected that since I did a pg_dump and then restored it when I re-loaded sonar I would see all of the same data. I do not have persistence enabled since I only run one pod. The only time there would be 2 pods would be temporarily during an upgrade. I was hoping that each new pod would connect to the same remote RDS db and there would be no data loss
This is happening without applying a license. I am unable to apply a license because I do not have the same domain name since I can’t switch it until the db is migrated.
Yes, all projects are in the RDS db, both old and new. I noticed that if I started up Sonar and create a new project (and verified that its in the RDS db) then restart the Sonar pod it will show no existing projects again.
The problem seems to be only on reading/loading what’s in the remote database. Searching for help with this has led me to various issues regarding elasticsearch and needing to delete a folder but because persistence is disabled there are no conflicting folders and everything comes up clean, just without whatever is supposed to get data from the remote db
in your sonarqube instance; are there some background tasks starting or failing when you bring it up connected to the RDS database?
Also can you check if the postgres schema is the same as with your previous configuration?
RDS is also known to need a manual VACUUM(full, analyze) after a restore in order to achieve good performance as documented here, so this is also something to try.
in theory sonarqube will check if there is data in elasticsearch and if not will get this data from the configured database. if there is no background task doing anything, it seems like sq is failing to find the required data in the configured database (wrong schema or bad permissions could be the cause).
Thanks for the info, I’ll start checking everything. From what I initially saw there are no errors in the logs and everything says its coming up fine. I am using the same version of sonar on both ends so the schema should be the same. I also tried having sonar connect to the db once before doing the upload as well as doing the upload before sonar connects at all but neither one worked. I’m not entirely sure what I’m looking for but I’ll dig around.
I’m not seeing anything indicating an error. What I do see is
INFO web[][o.sonar.db.Database] Create JDBC data source for jdbc:postgresql://my.db:5432/dbname
INFO web[][o.s.s.p.ServerFileSystemImpl] SonarQube home: /opt/sonarqube
INFO web[][o.s.s.u.SystemPasscodeImpl] System authentication by passcode is disabled
INFO web[][o.s.s.p.ServerPluginRepository] Deploy plugin .... (lots of these)
INFO web[][o.s.s.p.d.m.c.PostgresCharsetHandler] Verify that database charset supports UTF8
INFO web[][o.s.s.p.w.MasterServletFilter] Initializing servlet filter org.sonar.server.platform.web.WebServiceFilter@607fc8e6 [pattern=UrlPattern{inclusions=[/api/system/migrate_db.*, ...], exclusions=[/api/components/update_key, ...]}]
INFO web[][o.s.s.a.EmbeddedTomcat] HTTP connector enabled on port 9000
INFO web[][o.s.s.p.UpdateCenterClient] Update center: https://update.sonarsource.org/update-center.properties (no proxy)
INFO web[][o.s.s.e.IndexCreator] Create index [metadatas]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [metadatas] creating index, cause [api], templates [], shards [1]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[metadatas][0]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type metadatas/metadata
INFO es[][o.e.c.m.MetaDataMappingService] [metadatas/3rgG7NvPT_Kv-FDrf4CyRA] create_mapping [metadata]
INFO web[][o.s.s.e.IndexCreator] Create index [components]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [components] creating index, cause [api], templates [], shards [5]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[components][4]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type components/auth
INFO es[][o.e.c.m.MetaDataMappingService] [components/ZIdoRPnRQ4Ox2pECP5_OMw] create_mapping [auth]
INFO web[][o.s.s.e.IndexCreator] Create index [projectmeasures]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [projectmeasures] creating index, cause [api], templates [], shards [5]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[projectmeasures][4]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type projectmeasures/auth
INFO es[][o.e.c.m.MetaDataMappingService] [projectmeasures/bBUGNKy2QdyT_KI5wRrXFg] create_mapping [auth]
INFO web[][o.s.s.e.IndexCreator] Create index [rules]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [rules] creating index, cause [api], templates [], shards [2]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[rules][0]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type rules/rule
INFO es[][o.e.c.m.MetaDataMappingService] [rules/BUBn0EpdRyKPgX3EW-4Y3w] create_mapping [rule]
INFO web[][o.s.s.e.IndexCreator] Create index [issues]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [issues] creating index, cause [api], templates [], shards [5]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[issues][4]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type issues/auth
INFO es[][o.e.c.m.MetaDataMappingService] [issues/OnbDmOXBQ3mmy7W_DfuB8g] create_mapping [auth]
INFO web[][o.s.s.e.IndexCreator] Create index [users]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [users] creating index, cause [api], templates [], shards [1]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[users][0]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type users/user
INFO es[][o.e.c.m.MetaDataMappingService] [users/GEJRWvxaTvGF_uVYHDOTlQ] create_mapping [user]
INFO web[][o.s.s.e.IndexCreator] Create index [views]
INFO es[][o.e.c.m.MetaDataCreateIndexService] [views] creating index, cause [api], templates [], shards [5]/[0], mappings []
INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[views][4]] ...]).
INFO web[][o.s.s.e.IndexCreator] Create type views/view
INFO es[][o.e.c.m.MetaDataMappingService] [views/bqkW6wGMRDyXRu-lkgXsgg] create_mapping [view]
INFO web[][o.s.s.s.LogServerId] Server ID: 2FA2E2B3-AXkPZsAp_vNhCVNaUJj3
WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/plugins/download
WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/permissions/search_templates
WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/alm_integrations/list_bitbucketserver_projects
WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/alm_integrations/search_bitbucketserver_repos
WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/alm_integrations/check_pat
WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/support/info
It looks like it connects but then doesn’t find anything and creates it all. This log is from right after a restart after I cleared /opt/sonarqube/data/es6
There are no “ERROR” level logs and the only “WARN” level log regarding ES is
WARN es[][o.e.d.c.s.Settings] [http.enabled] setting was deprecated in Elasticsearch and will be removed in a future release! See the breaking changes documentation for the next major version.
@Tobias_Trabelsi We’re installing the same version of Sonar so the schema is the same and we double checked this by manually going to the database using the same credentials that are given to Sonar. We see all of the data expected when we go in ourselves and if we make a new project via the Sonar UI we do see it in the database. Everything seems to be working except Sonar reading from the DB. It can write, we know that much. The user we’re giving to Sonar has both read and write access though.
can you increase the log level to DEBUG to see a little more? until now this looks like the intended behavior except that the elasticsearch data is not populated correctly with the data in your database.
The warning regarding the http.enabled setting is not relevant to your problem.
one thought; you are working in a staging env so not production. can you update the sonarqube image for tests? in theory sonarqube should detect the state of the database and prompt for a database migration to happen. if this does not happen as well, sonarqube does not read anything from the database and the issue is there.