Checklist
[ ] I have read intro post: About the Installation Issues category
[ ] I have read the tutorials, help and searched for similar issues
[ ] I provide relevant information about my server (component names and versions, etc.)
[ ] I provide a copy of my logs and healthcheck
[ ] I describe the steps I have taken to trouble shoot the problem
[ ] I describe the steps on how to reproduce the issue
I am trying to move my docker to another server…
I am using Docker-compose
i get this problem the make passbolt doesn’t start:
passbolt_1 | Some tables are already present in the database, a new installation would override existing data.
passbolt_1 | Please use --force to proceed anyway.
passbolt_1 | PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘folders’ already exists in /var/www/passbolt/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:184
passbolt_1 | Stack trace:
How can I fix that:
I have moved the docker folder to the new server. I have moved the certification.
docker-compose up -d
69a10fdf8d04 passbolt/passbolt:latest-pro “docker-php-entrypoi…” 9 minutes ago Exited (1) 6 minutes ago passbolt_docker_passbolt_1
e0bf6cd29adc mariadb:10.3 “docker-entrypoint.s…” 9 minutes ago Up 6 minutes 127.0.0.1:3306->3306/tcp passbolt_docker_db_1
although passbolt doesn’t start i restored the database.
but the issue is
passbolt_1 | == 20191119092944 V2130AddFoldersTable: migrating
passbolt_1 | PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘folders’ already exists in /var/www/passbolt/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:184
passbolt_1 | Stack trace:
@Ahmad hello, seems like you are using passbolt pro, you should get in touch with support@passbolt.com for help.
“Table are already present” error generally appears when you have a mix match between passbolt versions (software, database content, database structure). For example this can happen when you reloaded content from a previous versions from backups in a database schema that was already migrated.
Long story short, you have the database structure of a new version, but you miss some of the content (such as which migration have been run). These issues are hard to fix as you need to manually match the structure and recreate database migrations table content.
Another way to fix this is to export the data that you have, check what is the highest migration version number in the phinx table (which list the migrations), and install this older version of passbolt, run the initial migration, load the data. Then you can upgrade again to the latest version.
That seems right
my old version is 2.12.1 and now without meaning I have 2.13.1
Can you help me with downgrading?
1- docker-compose down
then I change in docker-compose-pro.yml
from
image: passbolt/passbolt:latest-pro
to
image: passbolt/passbolt:2.12.1
2- then docker-compose up
Is that right?
I did that and that worked… THANKS
I did that in a new server. I am really afraid to do that in the production server. Is that safe to drop those tables. will I lose any information?
It’s not sufficient to downgrade the code, you need both the code from v2.12.1 and database structure from v2.12.1. We don’t have official instruction to downgrade, it depends on your case (e.g where is your database, etc.). Basically the process is take your v2.12 backup and install a v2.12 software on a clean DB, load your v2.12 backup data.
It’s hard to tell. Most likely you will only loose “Folders” information if at some point you were running v2.13.1 in production. Maybe you will have some other data issues if you were running previous version of the software against new database schema version. Or a mix of both depending on what you did. The best is load your production data into a staging environment, try it, see if it works.
To be honest it’s hard to advise without knowing which operations you did and in which order. I would need to know which version of the software you ran against which version of the database structure, and when was data loaded from v2.12 backup, then look at the log to check what users did during that time, etc.
Database structure, data and software version are meant to be in sync and are not always backward/forward compatible, as you experienced. You can always run the data cleanup tool afterwards to check for consistency issue:
Database structure, data and software version are meant to be in sync
Can you please check if I have the right docker-compose-pro.yml
version: ‘3.4’
services:
db:
image: mariadb:10.3
env_file:
- env/mysql.env
volumes:
- database_volume:/var/lib/mysql
ports:
- “127.0.0.1:3306:3306”
@Ahmad from the look of it you should be able to upgrade the production database without the issue you faced on your test server, since the schema in your test environment and production were not the same.
If you want to be sure, pick up the database data and structure from the production database, load it in your test server and run the migration.
This is because you are loading the data in an already migrated schema. You need to make a backup of both the schema (create tables statements) and the data (insert statements). You need to load this in a clean test database without any tables (drop the tables first). From there you will be able to have the same database (schema and data) that your production environment, and test that the migration works as intended.
I don’t know exactly how to do that… I just take backup via mysqldump and the restore it…
If you can help with more details about: make a backup of both the schema (create tables statements) and the data (insert statements). You need to load this in a clean test database without any tables (drop the tables first).
I would be very thankful…
@Ahmad ok I understand your problem. Basically when you do a mysqldump it will contain the schema and data and do a “drop table if exist”, but it will not drop tables that are “not there” in the mysqldump but already in your test database. So it will only drop tables that are in production, not more.
So the easiest is just to cleanup your test database completely prior to loading your data from your production mysqldump, so something like:
drop database passbolt_test;
create database passbolt_test COLLATE utf8mb4_unicode_ci;
