debian-mirror-gitlab/doc/development/database_debugging.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

178 lines
6.8 KiB
Markdown
Raw Normal View History

2021-01-03 14:25:43 +05:30
---
stage: Enablement
group: Database
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2021-01-03 14:25:43 +05:30
---
2020-07-28 23:09:34 +05:30
# Troubleshooting and Debugging Database
2018-03-17 18:26:18 +05:30
This section is to help give some copy-pasta you can use as a reference when you
run into some head-banging database problems.
2019-12-21 20:55:43 +05:30
An easy first step is to search for your error in Slack, or search for `GitLab <my error>` with Google.
2018-03-17 18:26:18 +05:30
2020-05-24 23:13:21 +05:30
Available `RAILS_ENV`:
2018-03-17 18:26:18 +05:30
2020-05-24 23:13:21 +05:30
- `production` (generally not for your main GDK database, but you may need this for other installations such as Omnibus).
- `development` (this is your main GDK db).
- `test` (used for tests like RSpec).
2018-03-17 18:26:18 +05:30
2020-10-24 23:57:45 +05:30
## Delete everything and start over
2018-03-17 18:26:18 +05:30
2020-05-24 23:13:21 +05:30
If you just want to delete everything and start over with an empty DB (approximately 1 minute):
2018-03-17 18:26:18 +05:30
2020-05-24 23:13:21 +05:30
```shell
bundle exec rake db:reset RAILS_ENV=development
```
2018-03-17 18:26:18 +05:30
2021-11-11 11:23:49 +05:30
If you want to seed the empty DB with sample data (approximately 4 minutes):
```shell
bundle exec rake dev:setup
```
2021-01-03 14:25:43 +05:30
If you just want to delete everything and start over with sample data (approximately 4 minutes). This
2020-05-24 23:13:21 +05:30
also does `db:reset` and runs DB-specific migrations:
2018-03-17 18:26:18 +05:30
2020-05-24 23:13:21 +05:30
```shell
2021-04-29 21:17:54 +05:30
bundle exec rake db:setup RAILS_ENV=development
2020-05-24 23:13:21 +05:30
```
2018-03-17 18:26:18 +05:30
2021-04-29 21:17:54 +05:30
If your test DB is giving you problems, it is safe to delete everything because it doesn't contain important
2020-05-24 23:13:21 +05:30
data:
2018-03-17 18:26:18 +05:30
2020-05-24 23:13:21 +05:30
```shell
bundle exec rake db:reset RAILS_ENV=test
```
2018-03-17 18:26:18 +05:30
## Migration wrangling
2019-09-30 21:07:59 +05:30
- `bundle exec rake db:migrate RAILS_ENV=development`: Execute any pending migrations that you may have picked up from a MR
- `bundle exec rake db:migrate:status RAILS_ENV=development`: Check if all migrations are `up` or `down`
- `bundle exec rake db:migrate:down VERSION=20170926203418 RAILS_ENV=development`: Tear down a migration
- `bundle exec rake db:migrate:up VERSION=20170926203418 RAILS_ENV=development`: Set up a migration
- `bundle exec rake db:migrate:redo VERSION=20170926203418 RAILS_ENV=development`: Re-run a specific migration
2018-03-17 18:26:18 +05:30
## Manually access the database
Access the database via one of these commands (they all get you to the same place)
2020-04-08 14:13:33 +05:30
```ruby
2018-03-17 18:26:18 +05:30
gdk psql -d gitlabhq_development
2020-04-22 19:07:51 +05:30
bundle exec rails dbconsole -e development
bundle exec rails db -e development
2018-03-17 18:26:18 +05:30
```
2019-09-30 21:07:59 +05:30
- `\q`: Quit/exit
- `\dt`: List all tables
- `\d+ issues`: List columns for `issues` table
- `CREATE TABLE board_labels();`: Create a table called `board_labels`
- `SELECT * FROM schema_migrations WHERE version = '20170926203418';`: Check if a migration was run
- `DELETE FROM schema_migrations WHERE version = '20170926203418';`: Manually remove a migration
2018-03-27 19:54:05 +05:30
2021-11-11 11:23:49 +05:30
## Access the database with a GUI
2021-11-18 22:05:49 +05:30
Most GUIs (DataGrid, RubyMine, DBeaver) require a TCP connection to the database, but by default
the database runs on a UNIX socket. To be able to access the database from these tools, some steps
2021-11-11 11:23:49 +05:30
are needed:
1. On the GDK root directory, run:
```shell
gdk config set postgresql.host localhost
```
1. Open your `gdk.yml`, and confirm that it has the following lines:
```yaml
postgresql:
host: localhost
```
1. Reconfigure GDK:
```shell
gdk reconfigure
```
1. On your database GUI, select `localhost` as host, `5432` as port and `gitlabhq_development` as database.
Alternatively, you can use the connection string `postgresql://localhost:5432/gitlabhq_development`.
The new connection should be working now.
2020-03-13 15:44:24 +05:30
## Access the GDK database with Visual Studio Code
Use these instructions for exploring the GitLab database while developing with the GDK:
1. Install or open [Visual Studio Code](https://code.visualstudio.com/download).
2021-03-11 19:13:27 +05:30
1. Install the [PostgreSQL VSCode Extension](https://marketplace.visualstudio.com/items?itemName=ckolkman.vscode-postgres).
2020-03-13 15:44:24 +05:30
1. In Visual Studio Code click on the PostgreSQL Explorer button in the left toolbar.
1. In the top bar of the new window, click on the `+` to **Add Database Connection**, and follow the prompts to fill in the details:
1. **Hostname**: the path to the PostgreSQL folder in your GDK directory (for example `/dev/gitlab-development-kit/postgresql`).
1. **PostgreSQL user to authenticate as**: usually your local username, unless otherwise specified during PostgreSQL installation.
1. **Password of the PostgreSQL user**: the password you set when installing PostgreSQL.
1. **Port number to connect to**: `5432` (default).
2021-03-11 19:13:27 +05:30
1. **Use an SSL connection?** This depends on your installation. Options are:
2020-03-13 15:44:24 +05:30
- **Use Secure Connection**
- **Standard Connection** (default)
2022-01-26 12:08:38 +05:30
1. **Optional. The database to connect to**: `gitlabhq_development`.
2020-03-13 15:44:24 +05:30
1. **The display name for the database connection**: `gitlabhq_development`.
Your database connection should now be displayed in the PostgreSQL Explorer pane and
you can explore the `gitlabhq_development` database. If you cannot connect, ensure
that GDK is running. For further instructions on how to use the PostgreSQL Explorer
Extension for Visual Studio Code, read the [usage section](https://marketplace.visualstudio.com/items?itemName=ckolkman.vscode-postgres#usage)
of the extension documentation.
2018-03-27 19:54:05 +05:30
## FAQ
### `ActiveRecord::PendingMigrationError` with Spring
2020-06-23 00:09:42 +05:30
When running specs with the [Spring pre-loader](rake_tasks.md#speed-up-tests-rake-tasks-and-migrations),
2018-03-27 19:54:05 +05:30
the test database can get into a corrupted state. Trying to run the migration or
dropping/resetting the test database has no effect.
2020-03-13 15:44:24 +05:30
```shell
2018-03-27 19:54:05 +05:30
$ bundle exec spring rspec some_spec.rb
...
Failure/Error: ActiveRecord::Migration.maintain_test_schema!
ActiveRecord::PendingMigrationError:
Migrations are pending. To resolve this issue, run:
bin/rake db:migrate RAILS_ENV=test
# ~/.rvm/gems/ruby-2.3.3/gems/activerecord-4.2.10/lib/active_record/migration.rb:392:in `check_pending!'
...
0 examples, 0 failures, 1 error occurred outside of examples
```
To resolve, you can kill the spring server and app that lives between spec runs.
2020-03-13 15:44:24 +05:30
```shell
2018-03-27 19:54:05 +05:30
$ ps aux | grep spring
eric 87304 1.3 2.9 3080836 482596 ?? Ss 10:12AM 4:08.36 spring app | gitlab | started 6 hours ago | test mode
eric 37709 0.0 0.0 2518640 7524 s006 S Wed11AM 0:00.79 spring server | gitlab | started 29 hours ago
$ kill 87304
$ kill 37709
```
2019-09-30 21:07:59 +05:30
### db:migrate `database version is too old to be migrated` error
Users receive this error when `db:migrate` detects that the current schema version
is older than the `MIN_SCHEMA_VERSION` defined in the `Gitlab::Database` library
module.
Over time we cleanup/combine old migrations in the codebase, so it is not always
possible to migrate GitLab from every previous version.
In some cases you may want to bypass this check. For example, if you were on a version
of GitLab schema later than the `MIN_SCHEMA_VERSION`, and then rolled back the
to an older migration, from before. In this case, in order to migrate forward again,
you should set the `SKIP_SCHEMA_VERSION_CHECK` environment variable.
2020-03-13 15:44:24 +05:30
```shell
2019-09-30 21:07:59 +05:30
bundle exec rake db:migrate SKIP_SCHEMA_VERSION_CHECK=true
```