Всем привет. Сейчас вот пересобрал окружение на ubuntu + docker4drupal и вижу массу проблем.
Например, если выполнить
drush sql-dump > test.sql
файл test.sql создается, но его размер 0 байт.
Версия d4d - 5.4.44.
drush 11, c 10-м то же самое.
Всем привет. Сейчас вот пересобрал окружение на ubuntu + docker4drupal и вижу массу проблем.
Например, если выполнить
drush sql-dump > test.sql
файл test.sql создается, но его размер 0 байт.
Версия d4d - 5.4.44.
drush 11, c 10-м то же самое.
Комментарии
drush status что говорит в этом проекте?
Drupal version : 9.3.8-dev
Site URI : http://default
DB driver : mysql
DB hostname : mariadb
DB port : 3306
DB username : docker5444
DB name : docker5444
Database : Connected
Drupal bootstrap : Successful
Default theme : bartik
Admin theme : seven
PHP binary : /usr/local/bin/php
PHP config : /usr/local/etc/php/php.ini
PHP OS : Linux
Drush script : /usr/local/bin/drush
Drush version : 11.0.6
Drush temp : /tmp
Drush configs : /var/www/html/vendor/drush/drush/drush.yml
Install profile : minimal
Drupal root : /var/www/html/web
Site path : sites/default
Files, Public : sites/default/files
Files, Temp : /tmp
Дамп БД делается через:
docker-compose exec -T php drush sql:dump > test.sql
Еще проблема была в синтаксисе подключения CSS файлов в теме оформления.
Вот так не работало (на хостинге работает)
mytheme.libraries.yml
css:
theme:
css/somestyle1.css: {}
css/somestyle2.css: {}
А вот так заработало:
version: 1.x
css:
theme:
css/somestyle1.css: {}
css/somestyle2.css: {}
Тему не закрываю еще пара моментов в новом окружении была.
А-а-а-а, не работает ничего!
Если дамп БД сделать через
docker-compose exec -T php drush sql:dump > test.sql
, то при попытке его импорта через drush пишет:
[13-Mar-2022 11:08:18 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
[13-Mar-2022 11:08:18 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
[13-Mar-2022 11:08:18 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
[13-Mar-2022 11:08:18 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
[13-Mar-2022 11:08:18 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
> ERROR 1064 (42000) at line 2: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'Deprecated: preg_match(): Passing null to parameter
>
> Deprecated: preg_match(...' at line 1
Дамп сделаный в том же окружении через adminer импортируется без проблем. Что делать? Как копии БД создавать?
Файл-то открывал вообще? Что там в строке 1 и в строке 2?
В 1й строке ничего. Начиная со 2-й:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /var/www/html/vendor/consolidation/site-alias/src/SiteSpecParser.php on line 144
-- MariaDB dump 10.19 Distrib 10.5.13-MariaDB, for Linux (x86_64)
--
-- Host: mariadb Database: allcasters2
-- ------------------------------------------------------
-- Server version 10.7.3-MariaDB
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `batch`
--
DROP TABLE IF EXISTS `batch`;
У тебя ошибки из консоли в файл попадают. Удали эти строки и файл будет импортироваться
Ну и надо разобраться почему вообще ошибки в консоли при экспорте дампа
Выполнил composer update - теперь drush создает файлы без этих строк в начале. Из этих файлов БД нормально восстанавливается.
НО: мне кажется что сайт работает быстрее если его БД воссоздана из дампа полученного через adminer, а не drush. Как подтвердить свою догадку?
Никак, это заблуждение
Специально секундомер включал. Разница при открытии одних и тех же страниц 4 и 24 секунды в зависимости было произведено восстановление из дампа сделанного через Adminer или через Drush. Кеш сбрасывал. Водку не пью. Можно как-то замерять и определить в чем причина?
А сами дампы если сравнить? Чем они отличаются? Это ж по идее текстовые файлы, должно быть просто сравнить.
Если и сравнивать, то без данных кэша. Но что-то мне подсказывает, что дело всё таки в кэше
Ну так если при сравнении выяснится, что один дамп содержит кэш, а второй - нет, то вот и ответ.
Если я на одной иснталяшке восстанавливаюсь из дампов, сбрасываю кеш в админке Друпала и все равно см одного дампа быстро работает, с другого - медленно.
Единственное правдоподобное объяснение, приходящее на ум - из одного из дампов не создаются индексы, либо таблицы создаются с типом MyISAM вместо InnoDB.
Проверь в "медленном" дампе наличие директив
PRIMARY KEY
,KEY
,ENGINE
и сравни с тем, что в "быстром" дампе.Это как проверить?
открыть дамп в текстовом редакторе и одновременно нажать на кнопочки [CTRL] и [F]
Везде
Начало медленного дампа
--
-- Host: localhost Database: allcasters2
-- ------------------------------------------------------
-- Server version 10.7.3-MariaDB
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `batch`
--
DROP TABLE IF EXISTS `batch`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `batch` (
`bid` int(10) unsigned NOT NULL COMMENT 'Primary Key: Unique batch ID.',
`token` varchar(64) CHARACTER SET ascii NOT NULL COMMENT 'A string token generated against the current user''s session id and the batch id, used to ensure that only the user who submitted the batch can effectively access it.',
`timestamp` int(11) NOT NULL COMMENT 'A Unix timestamp indicating when this batch was submitted for processing. Stale batches are purged at cron time.',
`batch` longblob DEFAULT NULL COMMENT 'A serialized array containing the processing data for the batch.',
PRIMARY KEY (`bid`),
KEY `token` (`token`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Stores details about batches (processes that run in…';
/*!40101 SET character_set_client = @saved_cs_client */;
Начало быстрого:
SET NAMES utf8;
SET time_zone = '+00:00';
SET foreign_key_checks = 0;
SET sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
SET NAMES utf8mb4;
DROP TABLE IF EXISTS `batch`;
CREATE TABLE `batch` (
`bid` int(10) unsigned NOT NULL COMMENT 'Primary Key: Unique batch ID.',
`token` varchar(64) CHARACTER SET ascii NOT NULL COMMENT 'A string token generated against the current user''s session id and the batch id, used to ensure that only the user who submitted the batch can effectively access it.',
`timestamp` int(11) NOT NULL COMMENT 'A Unix timestamp indicating when this batch was submitted for processing. Stale batches are purged at cron time.',
`batch` longblob DEFAULT NULL COMMENT 'A serialized array containing the processing data for the batch.',
PRIMARY KEY (`bid`),
KEY `token` (`token`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Stores details about batches (processes that run in…';
F12 - Network - открыть интересующую страницу
Посмотреть как и на что тратится это время.
Тут что-то видно (?):
1)
2)
Очень странно, но:
1. Если на своем ПК восстанавливаюсь с "медленного" дампа,
потом делаю из сайта дамп Admin-ером
и уже восстанавливаюсь с этого дампа
- все работает намного быстрее.
2. Когда переношу все это на реальный хостинг (Патруль) - там работает одинаково быстро с обеих дампов.