Блог

У меня странная проблема с облачным запуском в регионе Цюрих.

Я развернул свое приложение из облачной сборки как:

    "--region",
     "europe-west6",
   "--platform",
        "managed",
   "--allow-unauthenticated",
   "--add-cloudsql-instances",
        "$PROJECT_ID:europe-west6:mysql",
  

Я вижу, что YAML и в интерфейсе установлены правильно.

Я ожидал /cloudsql/project:europe-west6:mysql , что путь к сокету unix будет там и будет создан, но на самом деле папка пуста.

Когда я перечисляю файлы из корневого каталога / , я вижу cloudsql , что папка настраивается

 Array
(
    [0] => .
    [1] => ..
    [2] => bin
    [3] => boot
    [4] => cloudsql
    [5] => dev
    [6] => etc
    [7] => home
    [8] => lib
    [9] => lib64
    [10] => media
    [11] => mnt
    [12] => opt
    [13] => proc
    [14] => root
    [15] => run
    [16] => sbin
    [17] => srv
    [18] => sys
    [19] => tmp
    [20] => usr
    [21] => var
)
  

но после того, как я перечислил файлы из /cloudsql папки, она пуста.

 Array
(
    [0] => .
    [1] => ..
)
  

Current script owner: root Я также напечатал это.

Итак, очевидно, я не понимаю, почему создается папка, но сокет unix не создается облачным запуском. Я попытался использовать интерфейс для удаления SQL-соединения, затем /cloudsql папка исчезает, и если я верну ее из UI или, либо gcloud run deploy /cloudsql , папка видна, но под ней нет файлов.

Я нахожусь под правами пользователя root, все разрешения должны быть установлены. Что может быть не так?

Серия ошибок с нашей стороны, служба облачного запуска работает нормально.

1. Пара проблем, которые могли привести к этой проблеме:

• общедоступный IP-адрес должен быть установлен в облачном SQL
• контейнерный клиент MySQL должен поддерживать версию MySQL. У нас были проблемы с тем, что MySQL 8 не поддерживался.
  Сообщение об ошибке было: Server sent charset (255) unknown to the client.

Теперь о файле сокета. Который не является обычным файлом. Некоторые языки программирования и некоторые реализации библиотек проверяют наличие этого файла.
Они могут проверять с неправильной функцией!!! Например, в PHP scandir не отображаются файлы сокетов, а только обычные каталоги и файлы. До сегодняшнего дня я не знал об этом и ранее сообщал о неправильном отчете.
Также в PHP is_file возвращает false для socket файлов типа. Правильный способ проверить это file_exists .

3. Кроме того, в дистрибутивах Linux могут отсутствовать файлы сокетов, которые я пытался делать, например:

 $ find / -type s
Array
(
    [0] => /dev/log
)
  

как вы видите, ничего не указано с /cloudsql/* тем же, если бы я запустил lsof -i
Я понятия не имею, почему файлы / cloudsql отсутствуют в списке. Может быть, вы можете это объяснить.

4.
Когда вы получаете: (HY000/2002): No such file or directory возможно, ваша настройка клиента MySQL по умолчанию, например, на PHP, есть /tmp/mysql.sock в php.ini, и он читает оттуда.

Требуется двойная проверка, как переопределить строку unix_socket подключения. Распространенные ошибки заключаются в том, что люди используют unix_socket:/cloudsql/socket с двойным двоеточием <- что неверно

общепринятый способ определения строки подключения с unix_socket=/cloudsql/socket

5. потенциально может быть другая причина, по которой ваш скрипт запускается так рано, что /cloudsql путь настроен неправильно. Я не смог это проверить.