Using sonar-db-copy to migrate databases and having issues

SonarQube Server / Community Build
1

Working to upgrade from SQ 6.7.6 to latest LTS, but need to move databases first.

source: SQ 6.7.6 on PostgreSQL 9.5
target: SQ 6.7.6 on SQL Server 2017

Running sonar-db-copy-1.3.1.480 to migrate data.
Seems to connect to both databases fine, but fails before importing data. Here is output:

09:49:17 INFO  **************** CONFIGURATION VERIFICATIONS ****************
09:49:17 INFO  Database SOURCE  has been reached at :         jdbc:postgresql://localhost/sonar
09:49:17 INFO  Database DESTINATION has been reached at :     jdbc:sqlserver://localhost:1450;databaseName=sonar
09:49:17 INFO  The versions of SonarQube schema migration are the same between source (1838) and destination (1838).
09:49:17 INFO  **************** SEARCH TABLES ****************
09:49:17 INFO  START GETTING METADATA IN SOURCE...
09:49:17 INFO  Catalog: sonar
09:49:17 INFO  Schema: public
09:49:17 INFO  Table to migrate: analysis_properties
09:49:17 INFO  Table to migrate: ce_activity
09:49:17 INFO  Table to migrate: ce_scanner_context
09:49:17 INFO  Table to migrate: ce_task_characteristics
09:49:17 INFO  Table to migrate: ce_task_input
09:49:17 INFO  Table to migrate: default_qprofiles
09:49:17 INFO  Table to migrate: duplications_index
09:49:17 INFO  Table to migrate: es_queue
09:49:17 INFO  Table to migrate: events
09:49:17 INFO  Table to migrate: file_sources
09:49:17 INFO  Table to migrate: group_roles
09:49:17 INFO  Table to migrate: groups
09:49:17 INFO  Table to migrate: groups_users
09:49:17 INFO  Table to migrate: internal_properties
09:49:17 INFO  Table to migrate: issue_changes
09:49:17 INFO  Table to migrate: issues
09:49:17 INFO  Table to migrate: loaded_templates
09:49:17 INFO  Table to migrate: manual_measures
09:49:17 INFO  Table to migrate: metrics
09:49:17 INFO  Table to migrate: notifications
09:49:17 INFO  Table to migrate: org_qprofiles
09:49:17 INFO  Table to migrate: organization_members
09:49:17 INFO  Table to migrate: organizations
09:49:17 INFO  Table to migrate: perm_templates_groups
09:49:17 INFO  Table to migrate: perm_templates_users
09:49:17 INFO  Table to migrate: perm_tpl_characteristics
09:49:17 INFO  Table to migrate: permission_templates
09:49:17 INFO  Table to migrate: plugins
09:49:17 INFO  Table to migrate: project_branches
09:49:17 INFO  Table to migrate: project_links
09:49:17 INFO  Table to migrate: project_measures
09:49:17 INFO  Table to migrate: project_qprofiles
09:49:17 INFO  Table to migrate: projects
09:49:17 INFO  Table to migrate: properties
09:49:17 INFO  Table to migrate: qprofile_changes
09:49:17 INFO  Table to migrate: qprofile_edit_groups
09:49:17 INFO  Table to migrate: qprofile_edit_users
09:49:17 INFO  Table to migrate: quality_gate_conditions
09:49:17 INFO  Table to migrate: quality_gates
09:49:17 INFO  Table to migrate: rule_repositories
09:49:17 INFO  Table to migrate: rules
09:49:17 INFO  Table to migrate: rules_metadata
09:49:17 INFO  Table to migrate: rules_parameters
09:49:17 INFO  Table to migrate: rules_profiles
09:49:17 INFO  Table to migrate: schema_migrations
09:49:17 INFO  Table to migrate: snapshots
09:49:17 INFO  Table to migrate: user_roles
09:49:17 INFO  Table to migrate: user_tokens
09:49:17 INFO  Table to migrate: users
09:49:17 INFO  Table to migrate: webhook_deliveries
09:49:17 INFO     50 TABLES GETTED.
09:49:17 INFO  START GETTING METADATA IN DESTINATION...
09:49:17 INFO  Catalog: sonar
09:49:17 INFO  Schema: sonar
Exception in thread "main" Can not find tables in database source.

Didn’t have “sonar” schema on SQL Server, so created it… but that didn’t fix the problem either… any help would be greatly appreciated!

Thanks!

2

Hi,

I’m confused. Your 6.7.6 instance is already using a Postgres DB? If so, there’s no need to migrate. If not, then you’ve got your parameters swapped.

“Source” is where the data lives now.
“Destination” is where you want to move it to.

 
HTH,
Ann

3

Thanks Ann… yeah I realize we could continue to use Postgres 9.5 but we’ve been mandated to move toward Windows related products ( :roll_eyes: I know…) and we have a larger support base for SQL Server databases.

1 Like
4

Hi,

Okay still confused, but on a different aspect. Which migrator are you using? The one provided by Support (in which case you ought to also have access to our team of professional Support Engineers) or the FLOSS one provided to get users off of MySQL? Because that one’s only going to work for a source DB that’s MySQL.

 
Ann

5

Hello,

Using the one provided by Support. My support model is through our internal enterprise support, which means I have to go through someone else within my company to ask questions… a long drawn out process, and I won’t make my deadlines unless I find faster ways to get my questions answered - which by the way, I truly appreciate you engaging me in a dialog.

Joe

6

Hi Joe,

I don’t have any experience/expertise with this. However sometimes some of our Support Engineers dip their toes in the community when they need a break. Maybe I can get one of them over here. (No promises.)

 
Ann

1 Like