wiki:UserGuidelines/Admin/DataMigration/Haiti

Version 23 (modified by Praneeth Bodduluri, 15 years ago) ( diff )

--

Haiti


Data Migration & Consistency

We want to be able to migrate data from Prod to Dev so that Testers / Documenters have real data to play with.

Easy as a 1-off:

/etc/init.d/apache2 stop
rm -rf /home/haiti/dev/databases
cp -ar /home/haiti/prod/databases /home/haiti/dev
/etc/init.d/apache2 start

Maintaining this should be possible via DataMigration#WebServices Web Services

Also want to be able to migrate from the current sqlite backend to MySQL

We often need to use this same tricks to deal with database consistency issues.

CSV

Beware DB locks!

  • Don't keep Web2Py shell open longer than necessary
  • Consider goign into Maintenance Mode on the Webserver & disabling the Web2Py cron in /etc/crontab
cd /home/haiti/web2py
python web2py.py -S prod -M -N
db.export_to_csv_file(open('db.csv','wb'))
Ctrl+D

Remove reference Tables from CSV file (don't want to import duplicates!)

NB Do CSV file edits in a text editor, not MS Excel (MS Excel makes the dumps unusable!)

NB Be careful of file permissions!

  • All files in the databases folder should be chown www-data:www-data
  • If the 1st run of the model happens in the Python shell, then they will be owned by root...
cd /home/haiti/web2py
python web2py.py -S dev -M -N
db.import_from_csv_file(open('db.csv','rb'))
db.commit()
Ctrl+D

Changing a Column type in Sqlite live

sqlite handles live migrations pretty well, however if there is existing data then a conversion from string to integer can cause problems. For a development system, the easiest solution is simply to remove all databases/* & restart, however this isn't possible for a live system:

vim /home/haiti/prod/models/00_db.py
    migrate = True

cd /home/haiti/prod
bzr pull

cd /home/haiti/web2py
python web2py.py -S prod -M

db(db.or_organisation.id > 0).select().export_to_csv_file(open('orgs.csv','wb'))
db.or_organisation.drop()
db.commit()
Ctrl+D

python web2py.py -S prod -M

db.or_organisation.import_from_csv_file(open('orgs.csv','rb'))
db.commit()
Ctrl+D

/etc/init.d/apache2 force-reload

vim /home/haiti/prod/models/00_db.py
    migrate = False

If the system is being heavily used, need to put up a holding page during this time to prevent data entry. For switching on maintenance.

cd /home/haiti
./maintenance.on

For switching off maintenance.

cd /home/haiti
./maintenance.off

Changing a set of Lookup Options live

We can easily amend the module_resource_opts = {} live in the code (usually models/module.py) however we need to migrate existing data (after backing it up, of course):

cd /home/haiti/prod
bzr pull

cd /home/haiti/web2py
python web2py.py -S prod -M

db(db.or_organisation.id > 0).select().export_to_csv_file(open('orgs.csv','wb'))
db(db.or_organisation.type == 4).update(type='')
db(db.or_organisation.type == 5).update(type='')
db.commit()
Ctrl+D

/etc/init.d/apache2 force-reload

If the system is being heavily used, need to put up a holding page during this time to prevent data entry. For switching on maintenance.

cd /home/haiti
./maintenance.on

For switching off maintenance.

cd /home/haiti
./maintenance.off

Dealing with database corruption

  1. We had problems with the or_organisation table - queries wouldn't complete.

The tracebacks included: ValueError: invalid literal for int() with base 10: '01/14/10 1'

By commenting out each field in turn in the model, discovered that this was the timestamp column which included this data.

(Note the file was also chown root:root!)

To fix this we needed to:

  • Delete column from model
    vim /home/haiti/prod/models/05_or.py
    
    resource = 'organisation'
    table = module + '_' + resource
    db.define_table(table, timestamp, deletion_status,
      # uuidstamp
    
  • Export as CSV
    cd /home/haiti/web2py
    python web2py.py -S prod -M -N
    db.or_organisation.export_to_csv_file(open('prod_orgs.csv','wb'))
    Ctrl+D
    
  • Drop table
    cd /home/haiti/web2py
    python web2py.py -S prod -M -N
    db.or_organisation.drop()
    db.commit()
    Ctrl+D
    
  • Rebuild Table
  • Reimport from CSV
    cd /home/haiti/web2py
    python web2py.py -S prod -M -N
    db.or_organisation.import_from_csv_file(open('prod_orgs.csv','rb'))
    db.commit()
    Ctrl+D
    
  1. rms_sms_request table couldn't be recreated

Since this part of the system is under active development, it was necessary to drop the table as part of the release process.

  • Although normally we can re-populate the tables from their source feeds simply using:
    cd /home/haiti/web2py
    python web2py.py -S prod -M -N
    feature_class_id = db(db.gis_feature_class.name == 'SMS').select().first().id
    db(db.gis_location.feature_class_id == feature_class_id).delete()
    db.rms_tweet_request.truncate()
    db.rms_sms_request.truncate()
    db.commit()
    Ctrl+D
    

However this didn't complete fully as there was still an associated view file in databases/ & hence when model tries to create:

  • SyntaxError: invalid table name: rms_sms_request

To resolve this:

  • Take site down (I did this the ugly way!)
    vim /etc/crontab
    /etc/init.d/apache2 stop
    
  • Backup all Data
    cd /home/haiti/prod
    mkdir databases2
    cp -ar databases/* databases2
    rm -rf databases
    
  • Copy data down locally to be able to analyse easily, export as CSV
    tar cvf prod_db.tar databases2
    gzip -9 prod_db.tar
    sz prod_db.tar.gz
    
  • Allow model to recreate databases (owned as www-data)
  • Restore Data
    • Edit CSV file using a text editor (not MS Excel!)
      • remove reference tables & intiial records which are created by models/zzz_1st_run.py (NB This didn't seem to work properly on this occasion!)
    • Import CSV segments to see which parts work:
      cd /home/haiti/web2py
      python web2py.py -S prod -M -N
      db.import_from_csv_file(open('prod_part1.csv','rb'))
      db.commit()
      Ctrl+D
      

Web Services

Better to avoid locks & do without SSH login

Notes

1) sqlite does seems to treat emails with different capitalizations as different entities. MySQL does not and can cause a problem during import if data is not clean.

2) Use of the INNODB engine for the db can lead to Integrity Errors during the first run and import -> Recommend MyISAM for now.


Haiti

Note: See TracWiki for help on using the wiki.