Skip to main content

Migration to Solar System from Manual Install

Migration to Solar System from Manual Install

Introduction​

Previously, you might have installed Sunrise server manually without using Solar System Orchestrator. This guide will help you migrate to Solar System from your manual installation.

Prerequisites​

  • Docker: For running the server and other components.
  • Git: For cloning the repositories.

Upgrading​

Setting up the Solar System​

info

Make sure to create a backup of the Sunrise using !backupdatabase command in-game before proceeding with the migration.

We are not responsible for any data loss or corruption that may occur during the migration. Please make sure to create backups of all databases before proceeding with the migration.

  1. Stop the Server: Ensure that Sunrise/Observatory/Sunshine containers are not running before making any changes. (Leave databases containers running.)

  2. Clone the Solar System repository: Clone the Solar System repository with submodules.

git clone --recursive https://github.com/SunriseCommunity/Solar-System.git
cd Solar-System
  1. Copy the configuration files: Copy the configuration files from your manual installation to the Solar System repository.
cp .env.example .env
cp Sunrise.Config.Production.json.example Sunrise.Config.Production.json
  1. Fill the configuration files: Fill the configuration files with your previous configuration values.

For example, if you were using appsettings.Production.json file, you can copy the values from it to the Sunrise.Config.Production.json file.

For the .env file, each value has a prefix of the component it belongs to. For example, SUNRISE_ prefix is for Sunrise, OBSERVATORY_ prefix is for Observatory, SUNSHINE_ prefix is for Sunshine.

Migrating data from sunrise database​

Create databases backups​

Sunrise database backup​

Before we are going to initialize the new databases, we need to create a backups of all Sunrsie services databases.

If you didn't create a backup of the Sunrise database already, you can do so by running the following command in-game to the server's bot1 while having superuser privileges.

!backupdatabase
Observatory database backup​

Now you can create a backup of the Observatory, to do so, follow the following steps:

Get the docker container ID of the database container by running the following command:

docker ps --no-trunc --format "{{.ID}} {{.Names}} {{.Ports}}"

And look for the database container, it should be named like observatory-postgres-1

1dce4dbf874e5840a71fc359369ee6ae61e5bd5b46e8baff66091821f1470009 observatory-postgres-1 0.0.0.0:5432->5432/tcp

Copy the first part of the container ID, in this case 1dce4dbf874e5840a71fc359369ee6ae61e5bd5b46e8baff66091821f1470009

Then run the following command to create a backup of the Observatory database:

$ docker exec -it <container_id> pg_dumpall -c -U <observatory_username> > dump_observatory_postgres.sql

After that, you should see a file named dump_observatory_postgres.sql in the current directory. Make sure it's not empty or doesn't contain any errors.

Sunshine database backup​

In comparison to other services, Sunshine database is stores as a single file in the data directory.

Make sure you located sunshine.db file in the data directory.

Applying database backups​

warning

After you create backups of all databases, please stop the services before applying the backups.

Leaving databases containers running can and probably will cause port conflicts, as by default solar system uses same ports as the manual installation.

To do so, run the following command:

docker ps --no-trunc --format "{{.ID}} {{.Names}} {{.Ports}}"

And look for the containers that are not databases, they shouldn't include db, mysql, postgres in their names.

After which, stop them by running the following command:

docker stop <container_id>

Example:


$ docker ps --no-trunc --format "{{.ID}} {{.Names}} {{.Ports}}"
1dce4dbf874e5840a71fc359369ee6ae61e5bd5b46e8baff66091821f1470009 observatory-observatory-1 0.0.0.0:3333->3000/tcp
...
$ docker stop 1dce4dbf874e5840a71fc359369ee6ae61e5bd5b46e8baff66091821f1470009

Before applying the backups, start the Solar System stack by running the following command:

./start.sh
tip

If you are on Windows, use .\start.bat instead.

After that, stop all the non-database containers as you did with the manual installation.

Applying Sunrise database backup​

Find the backup snapshot you made earlier, it should be named like Backup_YYYYMMDDHHMMSS.zip and located in the Database/Backups directory.

Inside the backup snapshot, you will find a file named backup_mysql_YYYYMMDDHHMMSS.sql. This is the database backup file.

Get the docker container ID of the database container by running the following command:

docker ps --no-trunc --format "{{.ID}} {{.Names}} {{.Ports}}"

And look for the database container, it should be named like osu-sunrise-infrastructure-mysql-sunrise-db-1

de72eaebe131634413be592186f7b5bab3a2b8970ca521394b9a57e77aa9aaa5 osu-sunrise-infrastructure-mysql-sunrise-db-1 33060/tcp, 0.0.0.0:3306->3306/tcp

Copy the first part of the container ID, in this case de72eaebe131634413be592186f7b5bab3a2b8970ca521394b9a57e77aa9aaa5

Then run the following command to apply clear all tables before applying the backup:

tip

Fill the <container_id>, <root username>, <root password> and <database_name> with the actual values.

Usually, the root username is root and the root password is root.

$ docker exec -it <container_id> mysql -u <root username> --password=<root password> <database_name>
DROP DATABASE IF EXISTS <database_name>;
CREATE DATABASE <database_name>;

The output should be like this:

mysql> DROP DATABASE IF EXISTS sunrise;
Query OK, 19 rows affected (0.354 sec)

mysql> CREATE DATABASE sunrise;
Query OK, 1 row affected (0.009 sec)

mysql> exit
Bye

Then apply the backup by running the following command:

$ cat backup_mysql_YYYYMMDDHHMMSS.sql | docker exec -i <container_id> mysql -u <root username> --password=<root password> <database_name>

After that, don't forget to move Data files from backup snapshot to the Data directory.

Applying Observatory database backup​

Find the backup snapshot you made earlier, it should be named dump_observatory_postgres.sql.

Get the docker container ID of the database container by running the following command:

docker ps --no-trunc --format "{{.ID}} {{.Names}} {{.Ports}}"

And look for the database container, it should be named like osu-sunrise-infrastructure-observatory-postgres-1

1dce4dbf874e5840a71fc359369ee6ae61e5bd5b46e8baff66091821f1470009 osu-sunrise-infrastructure-observatory-postgres-1 0.0.0.0:5432->5432/tcp

Copy the first part of the container ID, in this case 1dce4dbf874e5840a71fc359369ee6ae61e5bd5b46e8baff66091821f1470009

tip

Fill the <container_id>, <username>, <database_name> with the actual values.

Usually, the username is admin and the database name is observatory.

Then run the following commands to apply the backup (in order):

$ docker exec -i <container_id> psql -U <username> -d postgres -c "DROP DATABASE IF EXISTS <database_name>;"
$ docker exec -i <container_id> psql -U <username> -d postgres -c "CREATE DATABASE <database_name>;"
$ cat dump_observatory_postgres.sql | docker exec -i <container_id> psql -U <username> -d <database_name>
tip

If you see ERROR: database "observatory" is being accessed by other users, make sure you stopped all the non-database containers and don't have any other processes accessing the database.

Applying Sunshine database backup​

Find the backup snapshot you made earlier, it should be named sunshine.db.

Move it to the Sunshine/data directory in the root of the Solar System repository.

Finishing up​

After you applied all the backups, you can start the server again.

Run the following command to start the server:

./start.sh

Please don't forget to rebuild global leaderboards, by running !flushcache yes_i_understand_what_im_doing command to the server's bot1 as a superuser.

Make sure all data was migrated correctly, by checking the Observatory and Sunrise logs. And of course you should see existing users and beatmaps while accesing the server.

If you didn't see any errors while migrating, but still don't see any data, wait a couple of minutes to make sure that the problem is not with the cached data.

Footnotes​

  1. Server Bot is the always online bot account that is used to interact with the server. Similar to the Tillerino on Bancho. Please don't confuse it with the BanchoBot. ↩ ↩2