table "django_content_type" already exists

Asked by Simon Trimboy on 2020-09-17

Hi,

I am trying to upgrade graphite from version 0.9.15 to 1.1.7

Initially this has worked as a clean install only by removing the existing /opt/graphite directory and upgrading python(2->3.x), sqlite, mod_wsgi, whisper, carbon and graphite-web.

I now need to upgrade this for production purposes and therefore need to persist all db data and attempt to upgrade in-place without removing the existing installation.

When I get to the Django webapp db setup steps I am having issues running the django-admin.py commands. I have run

export DJANGO_SETTINGS_MODULE=graphite.settings
export PYTHONPATH=/opt/graphite/webapp

/usr/local/bin/django-admin.py collectstatic
709 static files copied to '/opt/graphite/static'.

/usr/local/bin/django-admin.py makemigrations
Migrations for 'account':
  /opt/graphite/webapp/graphite/account/migrations/0002_auto_20200917_1608.py
    - Alter field history on profile
Migrations for 'events':
  /opt/graphite/webapp/graphite/events/migrations/0002_auto_20200917_1608.py
    - Alter field tags on event

When I run the migrate command I get the following error:

/usr/local/bin/django-admin.py migrate --run-syncdb
Operations to perform:
  Synchronize unmigrated apps: browser, composer, functions, messages, metrics, render, staticfiles, whitelist
  Apply all migrations: account, admin, auth, contenttypes, dashboard, events, sessions, tagging, tags, url_shortener
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  Applying contenttypes.0001_initial...Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql)
  File "/usr/local/lib/python3.8/site-packages/django/db/backends/sqlite3/base.py", line 394, in execute
    return Database.Cursor.execute(self, query)
sqlite3.OperationalError: table "django_content_type" already exists

I have read that using --fake-initial can help... but I run into similar exception albeit against a different table

/usr/local/bin/django-admin.py migrate --fake-initial --run-syncdb
Operations to perform:
  Synchronize unmigrated apps: browser, composer, functions, messages, metrics, render, staticfiles, whitelist
  Apply all migrations: account, admin, auth, contenttypes, dashboard, events, sessions, tagging, tags, url_shortener
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  Applying dashboard.0001_initial...Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql)
  File "/usr/local/lib/python3.8/site-packages/django/db/backends/sqlite3/base.py", line 394, in execute
    return Database.Cursor.execute(self, query)
sqlite3.OperationalError: table "dashboard_dashboard" already exists

Is it even possible to migrate the data between these versions - 0.9.15 to 1.1.7 ?

Regards

Question information

Language:
English Edit question
Status:
Solved
For:
Graphite Edit question
Assignee:
No assignee Edit question
Solved by:
Simon Trimboy
Solved:
Last query:
Last reply:
Denis Zhdanov (deniszhdanov) said : #1

I would say it's not only Graphite but Django problem. 0.9.15 was probably running on Django 1.4, and you're trying running 1.1.7 on 3.0.x (?), It's jumping over 2 major Django and 2 major Graphite versions - quite bold move IMO, over 8 years of changes!
(e.g. Django even recommeding not jumping even over feature releases).

Sorry, but I can't give you any recommendations. I would say minimally viable upgrade path will look like:

0.9.15 -> 1.0.0 / django 1.4 -> 1.9.13 / python 2.7
1.0.0 -> 1.1.0 / django 1.9.13 -> 1.11.29 / python 3
1.1.0 -> 1.1.7 / django 1.11.29 -> 2.0.13 -> 2.1.15 -> 2.2.16 -> 3.0.10 / python 3

but I can't give you any guarantees that will work. Mabe you can cut some corners with Django upgrade and do 1.11 -> 3.0.10.
Maybe you can do test it on VM first.
Or export useful data from old DB and reimport it in new DB directly.

Simon Trimboy (simontrimboy) said : #2

Ok np thanks for the prompt reply Denis.

Simon Trimboy (simontrimboy) said : #3

Name: Django
Version: 3.0.10