table "django_content_type" already exists

Asked by Simon Trimboy

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:
Revision history for this message
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.

Revision history for this message
Simon Trimboy (simontrimboy) said :
#2

Ok np thanks for the prompt reply Denis.

Revision history for this message
Simon Trimboy (simontrimboy) said :
#3

Name: Django
Version: 3.0.10