ddev: `ddev import-db` Removal of DDL statements in SQL dump can corrupt data if it contains DDL in the data
Describe the bug
I have SQL exported from my prod server (MySQL 5.7) using drush sql:dump
into a gzip SQL file.
I import it into my multisite setup like this:
ddev import-db --target-db=SITE --src=/Users/nthompson/Downloads/SITE.sql.gz
However… The node__body
table is empty. There are no errors shown during import. The SQL file definitely has INSERT statements for this table.
If I to to PHPMyAdmin and import the same SQL file, the table then has data in it.
Equally, if I import it via SequelPro (invoked using ddev sequelpro
, the same gzip file produces a DB with data in node__body
.
I cannot see any “verbose” or “debug” flags on import-db
to see what commands it runs.
Other tables do have data in them, although I’ve not done extensive inspection to see if its complete or there are is other missing data. The missing node body is enough of a bug for me at the moment 😉
To Reproduce
Command above: Simply import the DB.
Version and configuration information (please complete the following information):
Host: Big Sur 11.1
Docker Desktop:
DDEV-Local version v1.16.2
db drud/ddev-dbserver-mariadb-10.2:v1.16.0
dba phpmyadmin:5
ddev-ssh-agent drud/ddev-ssh-agent:v1.16.0
docker 20.10.2
docker-compose 1.27.4
os darwin
router drud/ddev-router:v1.16.2
web drud/ddev-webserver:v1.16.2
Config:
name: tmj-d8
type: drupal8
docroot: web
php_version: "7.4"
webserver_type: nginx-fpm
router_http_port: "80"
router_https_port: "443"
xdebug_enabled: false
additional_hostnames: []
additional_fqdns: []
mariadb_version: ""
mysql_version: "5.7"
provider: default
use_dns_when_possible: true
composer_version: ""
disable_settings_management: true
.ddev/config.multisite.yaml
additional_hostnames:
- tmj
- ktw
hooks:
post-start:
- exec: mysql -uroot -proot -e "CREATE DATABASE IF NOT EXISTS tmj; GRANT ALL ON tmj.* to 'db'@'%';"
service: db
- exec: mysql -uroot -proot -e "CREATE DATABASE IF NOT EXISTS ktw; GRANT ALL ON ktw.* to 'db'@'%';"
service: db
Let me know if there is anything you’d like me to test…
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23 (11 by maintainers)
Commits related to this issue
- Be way less aggressive with removing CREATE DATABASE or USE statuements in ddev import-db, fixes #2787 — committed to rfay/ddev by rfay 3 years ago
- Be way less aggressive with removing CREATE DATABASE or USE statuements in ddev import-db, fixes #2787 — committed to rfay/ddev by rfay 3 years ago
- Be way less aggressive with removing CREATE DATABASE or USE statuements in ddev import-db, fixes #2787 — committed to rfay/ddev by rfay 3 years ago
The problem is https://github.com/drud/ddev/blob/37ac5f0893c82d18e077d7e1469c4200205b681e/pkg/ddevapp/ddevapp.go#L511-L516
We remove DROP TABLE and such in order to keep people from shooting themselves in the foot with bad dumpfile imports. Obviously there are consequences of that and the regex will have to be better!
The node in question actually contains the text “DROP DATABASE” 😃
@njt1982 you’re awesome. Your careful notice of this has resulted in fixing a nasty bug. Just for fun look at the blog post that broke ddev.com when it accidentally got imported into DDEV-Local, https://www.ddev.com/ddev-local/ddev-local-database-management/ - look familiar?
For a test, to create a dump that has the database name in it,
ddev exec -s <database> mysqldump --databases db >~/tmp/junk.sql
Hi @rfay - definitely want to resolve it. It’s just been “one of those weeks” 😉