When I try the command

drush sql:sync @dev.dev @self or drush sql:sync @dev.dev @local it errors with:

Undefined class constant 'MYSQL_ATTR_SSL_CA' in Drush\Sql\SqlMysql->creds() (line 60 of /Users/kevinquillen/Servers/foo/vendor/drush/drush/src/Sql/SqlMysql.php). [error] Drush command terminated abnormally due to an unrecoverable error. [5.47 sec, 7.92 MB] [error] Failed to import /tmp/foo_20180405_152230.sql.gz into target. [5.48 sec, 7.91 MB]

Previously, I could do drush sql-sync @source @destination and it worked just fine (from the host OS).

Not really sure where to go from here, I recently upgraded from Drush 8 to 9. The problem also happens on another project.

drush @local sql:connect -vvv works. A basic query with sql:query also works.

Why can't I sync from remote to local anymore after the upgrade?

Remote environment: Acquia Cloud

Local environment: DrupalVM

DrupalVM config.yml:

# Update the hostname to the local development environment hostname.
vagrant_hostname: local.mysite.com
vagrant_machine_name: mysite

# Set the IP address so it doesn't conflict with other Drupal VM instances.

# Use Ubuntu 16.04 LTS to match Acquia Cloud environments.
vagrant_box: geerlingguy/ubuntu1604

# Set drupal_site_name to the project's human-readable name.
drupal_site_name: "My Site"

# Provide the path to the project root to Vagrant.
  # Set the local_path for the first synced folder to `.`.
  - local_path: .
    # Set the destination to the Acquia Cloud subscription machine name.
    destination: /var/www/mysite
    type: nfs

drupal_build_composer_project: false
# Toggling this to `true` would invoke `composer install` with the
# projects own `composer.json` successfully.
drupal_build_composer: false
drupal_composer_path: false
drupal_composer_install_dir: "/var/www/mysite"
drupal_core_path: "/var/www/mysite/docroot"
ssh_home: /var/www/mysite

drupal_db_user: drupal
drupal_db_password: drupal
drupal_db_name: drupal

# Set this to 'false' if you don't need to install drupal (using the drupal_*
# settings below), but instead copy down a database (e.g. using drush sql-sync).
drupal_install_site: false

# Drupal VM automatically creates a drush alias file in your ~/.drush folder if
# this variable is 'true'.
configure_drush_aliases: false

# This is required for front-end building tools.
nodejs_version: "9.x"
  - name: bower
  - name: gulp-cli
  - name: yarn
nodejs_install_npm_user: "{{ drupalvm_user }}"
npm_config_prefix: "/home/{{ drupalvm_user }}/.npm-global"
  #- adminer
  - drupalconsole
  - drush
  - mailhog
  - memcached
  - nodejs
  #- solr
  #- selenium
  - xdebug

# PHP 5.6 (PHP 7.1 is being tested, see: https://docs.acquia.com/node/25726).
php_version: "7.1"
php_install_recommends: no
php_memory_limit: "256M"
php_display_errors: "On"
php_display_startup_errors: "On"
php_realpath_cache_size: "1024K"
php_sendmail_path: "/opt/mailhog/mhsendmail"
php_opcache_enabled_in_ini: true
php_opcache_memory_consumption: "192"
php_opcache_max_accelerated_files: 4096
php_max_input_vars: "4000"

  - "php{{ php_version }}-bz2"
  - "php{{ php_version }}-imagick"
  - imagemagick

# XDebug configuration.
# Change this value to 1 in order to enable xdebug by default.
php_xdebug_default_enable: 1
php_xdebug_coverage_enable: 0
# Change this value to 1 in order to enable xdebug on the cli.
php_xdebug_cli_enable: 0
php_xdebug_remote_enable: 1
php_xdebug_remote_connect_back: 1
# Use PHPSTORM for PHPStorm, sublime.xdebug for Sublime Text.
php_xdebug_idekey: PHPSTORM
php_xdebug_max_nesting_level: 256
php_xdebug_remote_port: "9000"

  - "../../../acquia/blt/scripts/drupal-vm/post-provision.php"
  • It just means one environment (probably local) doesn’t have the php MySQL extension installed/enabled. Remember CLI and Mod Apache/fpm can have different config so it could be working happily for web in whatever environment’s missing the extension, but could be separately missing for CLI. You could also have multiple php installations on the same box and drush could be connecting to the wrong one – Clive Apr 5 '18 at 18:05
  • So I did that, and now it says 'mysql: command not found'. How can I get it to execute those commands in the VM instead of my host machine? – Kevin Apr 5 '18 at 18:28
  • Literally by executing them in the vm - ssh would be the most traditional way, but your environment might offer something different or a shortcut – Clive Apr 5 '18 at 18:35
  • Assuming you’re using DrupalVM, have you read the upgrade notes? – Clive Apr 5 '18 at 18:37
  • Let me check that. If I do it in the VM it seems I would have to add my ssh keys to the remote server, which seems odd with a VM? The sql-dump | sql-cli appears to have worked. – Kevin Apr 5 '18 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.