Version mismatch with Postgres 16 & pg_dump #6139
Comments
|
The issue here is that you need to use pg_dump in the db container, so |
Ah…hmmm that makes things difficult for Craft's own backup command, |
|
Yes, it's a bit shortsighted of Craft to think that the db server is always on the same server (or even that pg_dump would be available). |
|
However, this is a general problem, see It happens in the mysql world with MySQL 8.0, which is sometimes on a very few things picky about the client version. However, it's quite difficult to install the correct version of pg_dump on Debian 12 Bookworm when it might be something between 10 and 16, and Debian only supports one of the above. Copying client binaries around between different versions of distros is complex and error-prone, with unknown implications. |
Perhaps, but when the app needs to initiate the process, I'm not sure how else we'd go about it. It seems like Drupal or any app that handles backing up its own database would have the same problem. Is it possible for a project type in DDEV to influence the resulting |
|
@timkelty, try this custom
The client version will (most likely) be different from the If this works well, we can probably add this layer to the DDEV |
|
Nice solution! Id didn't know there were separate packages for pg_dump. Is there something like that where we can get the mysql version of the client also? |
I'm pretty sure that the CMSs I'm familiar with use the mysql API to do their work. The only one I'm really familiar with is the backup_and_migrate module in Drupal, which AFAIK uses the database API rather than relying on a local tool. |
I'd agree for Postgres, but I'm not sure for MySQL. We've seen plenty of examples of where a dump generated by a
Keep in mind, I have very little Drupal experience. But by MySQL API, you mean https://www.php.net/manual/en/book.mysqli.php? That's what Drupal's backup/migrate module appears to use, anyway. https://github.com/backupmigrate/backup_migrate_core/blob/master/src/Source/MySQLiSource.php Which is something we're trying to avoid, as doing a 50GB db backup using PHP is generally considered a bad idea. Interestingly, Drush does appear to rely on Which would be a problem in this scenario where the client tool that is available is different than the one that is in the database container. |
|
All that said... as an SA I wouldn't want to rely on a PHP application claiming to do backups. I'd want to do them at the system level (which is |
|
FWIW, Craft 1 & 2 used PHP to backup databases back in the day (like Drupal appears to do now). We ditched it for lots of reasons and decided to rely on native tooling ( It’s solved tons of problems for us compared to the old way. The only real headache we’ve noticed from making the swap is version mismatches between client and server tooling (not specific to DDEV, but it does occur here and the related #6083). |
Is there an existing issue for this?
Output of
ddev debug testExpand `ddev debug test` diagnostic information
Expected Behavior
pg_dumpshould work viaddev exec pg_dumpActual Behavior
Steps To Reproduce
ddev exec pg_restoreThe text was updated successfully, but these errors were encountered: