< Niklaus.20180129-migel-dateformat | Index | Niklaus.20180123-postgres10 >>
Checked that now the migel script did not show many errors.
But at the end the migel backup script did throw the following error
2018-01-24 13:46:23 +0100: historicize /var/www/migel/data/csv/migel_products_it.csv.gz -> /var/www/migel/data/csv/migel_products_it-2018.01.24.csv.gz. Size is 541819
cp -p /var/www/migel/data/csv/MiGeL.xls /var/www/migel/data/csv/MiGeL-2018.01.24.xls
NOTICE: table "migel_fulltext_index_de" does not exist, skipping
Traceback (most recent call last):
17: from jobs/update_migel_products_with_report:10:in `<main>'
16: from jobs/update_migel_products_with_report:11:in `<module:Migel>'
15: from jobs/update_migel_products_with_report:12:in `<module:Util>'
14: from /var/www/migel/lib/migel/util/job.rb:22:in `run'
13: from jobs/update_migel_products_with_report:15:in `block in <module:Util>'
12: from /var/www/migel/lib/migel/util/server.rb:280:in `init_fulltext_index_tables'
11: from /var/www/migel/lib/migel/util/server.rb:383:in `rebuild_fulltext_index_tables'
10: from /var/www/migel/lib/migel/util/server.rb:329:in `rebuild_fulltext_index_table'
9: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/cache.rb:336:in `fill_index'
8: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:65:in `fill'
7: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:65:in `each'
6: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:68:in `block in fill'
5: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:68:in `each'
4: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:69:in `block (2 levels) in fill'
3: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:69:in `each'
2: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:70:in `block (3 levels) in fill'
1: from /var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/index.rb:388:in `do_update_index'
/var/www/migel/vendor/ruby/2.5.0/gems/odba-1.1.4/lib/odba/storage.rb:596:in `update_fulltext_index': wrong number of arguments (given 4, expected 5) (ArgumentError)
We should really have a look whether we can make the odba unit tests work again. Done with commit Fixed unit tests to adapt to IF (NOT) EXISTS. I had not updated the unit test after I introduced dropping indices/tables before recreating them.
But the problem is, that here the mocks just test, whether we a call is made, but does not really exercise the ODBA. Again a case where mocking was just done to report good coverage, but not to exercise the class under test!
It would be must better to use a real in memory database eg. using sqlite3. And how many days did I loose, because I could not properly exercise the ODBA when writing tests
Checking whether the backup script worked fine. No, as /var/backup/thinpower/db/postgresql/January-2018/2018-01-22 is empty? Maybe we are missing a PATH/LD_LIBRARA. Running the script by hand. It cannot contact the server as we are running now on port 5433 and not 5432. The newt pg_backup.sh has a variable PARAM_PGHOST which we could use to connect via another port. Modifying it use the needed variables for thinpower.
But the new backup got to a different place and name: Currently we had for januay 21 2018 /var/backup/thinpower/db/postgresql/January-2018/2018-01-2 files like 22:00-postgresql_database-yus-backup.gz.
The new one was placed into /var/backup/thinpower/db/postgresql/2018-01/ and named pg_db-127.0.0.1-yus-backup-2018-01-24-0833.bz2 (I used 127.0.0.1 as hosstname).
Modifying the script and using variables to hold the backup_destination which is used several times as $PGBACKUPDIR/$subdir/pg_db-$PGHOST-$i-backup-$date_info-$current_time
Pushed the changes (inlcuding some other scripts) via commit Added some scripts
We are using now bzip2 as compression tool, as it generates clearly smaller files, eg. migel db dump is now 5.6M, whereas before it used 10M.
But backups on thinpower takes 5 or 10 times as much time as on oddb-ci2.