Использование MySQL в качестве СУБД

DNSmanager по умолчанию использует в качестве СУБД (системы управления базами данных) SQLite. Эту СУБД удобно использовать при небольших объёмах данных и низких нагрузках, что характерно для DNSmanager. Однако, если в DNSmanager добавлено большое количество доменов и к нему поступает большое количество конкурентных запросов, рекомендуем использовать СУБД MySQL.

Алгоритм перехода с SQLite на MySQL

Алгоритм состоит из шагов:

  1. Установите и запустите MySQL:

    Для CentOS

    yum install mariadb-server
service mariadb start

    BASH

    Для Debian

    apt-get install mysql-server
service mysqld start

    BASH

  2. Измените стандартное имя файла core: 

    mv /usr/local/mgr5/bin/core /usr/local/mgr5/bin/core2

    CODE

  3. Остановите процесс core: 

    pkill core

    CODE

  4. Создайте в MySQL базу данных:

    create database dnsmgr default character set utf8mb4;

    BASH

  5. Замените в конфигурационном файле DNSmanager (по умолчанию /usr/local/mgr5/etc/dnsmgr.

    conf) строку «DBType sqlite» на «DBType mysql».

  6. Также в конфигурационном файле укажите параметры подключения к базе данных:
    • DBHost — адрес сервера с MySQL, на котором находится база данных. По умолчанию — «localhost»;
    • DBUser — пользователь базы данных. По умолчанию — «root»;
    • DBPassword — пароль пользователя базы данных, заданного параметром DBUser;
    • DBName — имя базы данных. По умолчанию — «dnsmgr».
  7. Если нужно, перенесите данные из SQLite в MySQL:

    1. Создайте дамп базы данных:

      sqlite3 /usr/local/mgr5/etc/dnsmgr.db .dump > /root/dnsmgr.db.sqlite

      BASH

       Пояснения

      /root/dnsmgr.db.sqlite — файл, в который будет записан дамп.

    2. Выполните замены в файле дампа:

       replace "BEGIN TRANSACTION" "START TRANSACTION" -- /root/dnsmgr.db.sqlite
 replace "PRAGMA foreign_keys=OFF;" "SET NAMES utf8mb4;" -- /root/dnsmgr.db.sqlite
 replace "ON CONFLICT FAIL" "" -- /root/dnsmgr. db.sqlite
 replace "usage VARCHAR(64)" "\`usage\` VARCHAR(64)" -- /root/dnsmgr.db.sqlite
 replace "noauto VARCHAR(3)" "\`noauto\` VARCHAR(3)" -- /root/dnsmgr.db.sqlite
 replace "DEFAULT \`off\`" "DEFAULT 'off'" -- /root/dnsmgr.db.sqlite
 awk 'FS = "\"" {if($1=="INSERT INTO ") {print($1$2$3)} else {print}}' /root/dnsmgr.db.sqlite > /root/dnsmgr.db.mysql

      BASH

    3. Разверните базу данных для MySQL из дампа:

      mysql -uroot -p dnsmgr < /root/dnsmgr.db.mysql

      BASH

       Пояснения

      /root/dnsmgr.db.sqlite — файл дампа.
  8. Перезапустите DNSmanager. Если перенос данных из SQLite в MySQL не был выполнен, то DNSmanager запустится с чистой базой данных.

  9. Верните файлу core стандартное имя: 

    mv /usr/local/mgr5/bin/core2 /usr/local/mgr5/bin/core

    CODE

  10. Перезапустите процесс core: 

    pkill core

    CODE

Скрипт конвертации

Для выполнения пунктов 2–10 алгоритма можно воспользоваться скриптом:

#!/bin/bash
mv /usr/local/mgr5/bin/core /usr/local/mgr5/bin/core2
pkill core
sqlite3 /usr/local/mgr5/etc/dnsmgr. db .dump > /root/dnsmgr.db.sqlite
replace "BEGIN TRANSACTION" "START TRANSACTION" -- /root/dnsmgr.db.sqlite
replace "PRAGMA foreign_keys=OFF;" "SET NAMES utf8mb4;" -- /root/dnsmgr.db.sqlite
replace "ON CONFLICT FAIL" "" -- /root/dnsmgr.db.sqlite
replace "usage VARCHAR(64)" "\`usage\` VARCHAR(64)" -- /root/dnsmgr.db.sqlite
replace "noauto VARCHAR(3)" "\`noauto\` VARCHAR(3)" -- /root/dnsmgr.db.sqlite
replace "DEFAULT \`off\`" "DEFAULT 'off'" -- /root/dnsmgr.db.sqlite
awk 'FS = "\"" {if($1=="INSERT INTO ") {print($1$2$3)} else {print}}' /root/dnsmgr.db.sqlite > /root/dnsmgr.db.mysql
mysql -e "create database dnsmgr default character set utf8mb4;"
mysql -uroot dnsmgr < /root/dnsmgr.db.mysql
grep -qE "DBType sqlite" /usr/local/mgr5/etc/dnsmgr.conf && replace "DBType sqlite" "DBType mysql" -- /usr/local/mgr5/etc/dnsmgr.conf
grep -qE "DBType mysql" /usr/local/mgr5/etc/dnsmgr.conf || echo "DBType mysql" >> /usr/local/mgr5/etc/dnsmgr.conf
rm -f /usr/local/mgr5/var/.db.cache.
 
 
 *
mv /usr/local/mgr5/bin/core2 /usr/local/mgr5/bin/core
pkill core

BASH

Сравнение MySQL и PostgreSQL в 2023 году / Хабр

PostgreSQL и MySQL — это надежные, безопасные и масштабируемые базы данных, которые существуют уже много лет. Каждая из них имеет уникальные сильные и слабые стороны, что делает какую‑либо из них более подходящей для конкретных нужд. В этой статье мы проведем их сравнение, чтобы помочь с принятием обоснованного решения в 2023 году.

Что касается выбора реляционной системы управления базами данных (РСУБД), то популярны два варианта — PostgreSQL и MySQL. Обе системы существуют уже несколько десятилетий и зарекомендовали себя как надежные, безопасные и масштабируемые. Однако они имеют различные сильные и слабые стороны, что делает одну из них более подходящей для конкретных случаев использования. В этой статье мы сравним PostgreSQL и MySQL, чтобы помочь вам принять обоснованное решение в 2023 году.

История и развитие

PostgreSQL была впервые выпущена в 1996 году и стала широко используемой СУБД с открытым исходным кодом. Она известна своей строгой приверженностью стандартам SQL, широким набором функциональных возможностей, а также вниманием к целостности и безопасности данных.

MySQL, с другой стороны, была впервые выпущена в 1995 году и широко применялась для веб‑приложений благодаря своей высокой производительности и простоте использования. Со временем компания Oracle приобрела систему управления базами данных MySQL с открытым исходным кодом и превратила ее в коммерческий продукт.

Функциональные возможности

PostgreSQL и MySQL предлагают широкий спектр возможностей в качестве систем управления реляционными базами данных, но между ними есть некоторые ключевые различия:

  1. Типы данных: PostgreSQL поддерживает более широкий спектр современных типов данных, включая массивы, hstore (хранилище типа “ключ-значение”) и JSONB (бинарный JSON), которые обеспечивают более гибкие и эффективные возможности хранения данных. С другой стороны, MySQL имеет ограниченный набор типов данных и ориентирован на более простые веб-приложения.

  2. Поддержка геопространственных данных: PostgreSQL поддерживает геопространственные данные, включая богатый набор типов данных, функций и операторов для работы с географическими данными. MySQL, хотя и имеет некоторую поддержку геопространственных данных, мог бы обладать большей функциональной мощью в этой области.

  3. Индексирование: В MySQL по умолчанию используется тип индекса B-tree, который хорошо подходит для большинства юзкейсов. PostgreSQL имеет более совершенную систему индексирования, чем MySQL, включая поддержку индексов B-tree, GiST (Generalized Search Tree. Обобщенное поисковое дерево) и GIN (Generalized Inverted Index. Обобщенный обратный индекс). Они предоставляют больше возможностей для оптимизации производительности запросов и поиска данных.

  4. Репликация: PostgreSQL и MySQL поддерживают репликацию баз данных, но методы и возможности репликации различны. PostgreSQL поддерживает мульти-мастер (с несколькими мастерами) репликацию, в то время как MySQL в основном поддерживает репликацию master-slave (ведущий-ведомый). Недавно MySQL представила новую модель репликации под названием Group Replication (групповая репликация), но это все еще относительно новая фича с некоторыми ограничениями.

  5. Транзакции: PostgreSQL и MySQL InnoDB используют MVCC (Multi-Version Concurrency Control. Многоверсионный контроль параллелизма) для обработки параллельного доступа к данным. Однако PostgreSQL предлагает развитые возможности управления транзакциями, такие как уровни изолированности транзакций, атомарные транзакции и точки сохранения. В отличие от этого, опции по управлению транзакциями в MySQL более ограничены. PostgreSQL может быть лучше для применения в приложениях, требующих высокого параллелизма или сложной логики транзакций.

  6. Хранимые процедуры: PostgreSQL и MySQL поддерживают хранимые процедуры, но язык и функциональность хранимых процедур различны. PostgreSQL поддерживает хранимые процедуры, написанные на различных языках, включая PL/pgSQL, PL/Tcl, PL/Perl и другие. MySQL, напротив, в основном поддерживает хранимые процедуры, написанные на языке SQL.

  7. Расширения: PostgreSQL имеет надежную платформу расширений, которая позволяет разработчикам добавлять пользовательские функции и расширять основные возможности базы данных. Хотя MySQL имеет некоторую поддержку расширений, уровень расширяемости у нее иной, чем у PostgreSQL.

Захват измененных данных

С точки зрения захвата измененных данных (CDC), как бинарные логи MySQL, так и журналы предзаписи (WAL) PostgreSQL могут фиксировать изменения, внесенные в базу данных. Однако конкретные возможности и использование CDC могут отличаться.

DBConvert Streams — это программное обеспечение, которое может читать журналы транзакций MySQL и PostgreSQL и преобразовывать записи в другой диалект, что делает его пригодным для репликации гетерогенных баз данных в режиме реального времени.

Производительность

MySQL известна своей высокой производительностью и способностью обрабатывать большие объемы данных. Она была оптимизирована для рабочих нагрузок с интенсивными операциями чтения данных и имеет быструю систему индексирования, которая помогает улучшить производительность запросов. Однако при выполнении операций записи могут возникать проблемы параллелизма, такие как блокировки, что приводит к снижению производительности. Это связано с реализацией блокировок на уровне таблиц, препятствующих любым действиям во время выполнения операции записи.

Для решения проблемы блокировок на уровне таблиц используется механизм хранения InnoDB. Это один из самых популярных и широко используемых механизмов хранения данных в экосистеме MySQL. InnoDB поддерживает блокировку на уровне строки, улучшая параллелизм для смешанных рабочих нагрузок.

Кроме того, недавняя разработка высокопроизводительного механизма хранения данных MyRocks еще больше улучшила способность MySQL справляться с интенсивными рабочими нагрузками, связанными с записью.

PostgreSQL разработана в качестве более универсальной системы, способной справляться как с рабочими нагрузками при интенсивных операциях чтения, так и при интенсивной записи, но с немного меньшей производительностью, чем MySQL, которая оптимизирована для больших нагрузок во время чтения. Однако в последних версиях PostgreSQL улучшила свою производительность, особенно в отношении сложных запросов и обработки данных.

Кроме того, PostgreSQL имеет более развитую систему индексирования по сравнению с MySQL, что может повысить производительность при выполнении сложных запросов. PostgreSQL также поддерживает расширенные типы данных, такие как массивы и JSONB, что может привести к более эффективному хранению и получению данных.

В конечном итоге, производительность PostgreSQL и MySQL зависит от различных факторов, таких как аппаратное обеспечение, объем данных и сложность запросов.

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

Масштабируемость

И MySQL, и PostgreSQL могут масштабироваться, однако в этом вопросе у них имеются свои сильные и слабые стороны.

MySQL часто предпочитают за ее горизонтальную масштабируемость, это означает, что ее можно масштабировать путем добавления новых узлов в кластер базы данных. Она идеально подходит для веб-приложений, которым необходимо обрабатывать большое количество одновременных соединений.

С другой стороны, PostgreSQL известна своей вертикальной масштабируемостью, то есть она может обрабатывать большие объемы данных и манипулировать вычислительными мощностями путем добавления дополнительных ресурсов, таких как память и процессор, на один узел. Она также поддерживает горизонтальное масштабирование с помощью таких технологий, как шардинг, которая позволяет разделять большие массивы данных на несколько узлов. PostgreSQL предпочтительна для приложений, требующих сложных запросов и транзакций, а также для рабочих задач в области хранения данных и бизнес-аналитики.

Что касается масштабируемости, учитывайте конкретные требования вашего приложения. Если вам необходимо обрабатывать большое количество параллельных соединений и требуется горизонтальная масштабируемость, MySQL может быть лучшим выбором. Однако PostgreSQL больше подходит, когда нужны сложные транзакции и запросы.

Стоимость

В 2023 году PostgreSQL по-прежнему является продуктом с открытым исходным кодом и ориентированной на сообщество, в то время как MySQL имеет более сложную историю лицензирования. MySQL изначально разрабатывалась как коммерческий продукт компанией MySQL AB, причем были доступны бесплатные и платные версии. Покупка MySQL AB компанией Oracle в 2010 году вызвала некоторые опасения среди разработчиков по поводу будущего статуса MySQL с открытым исходным кодом. Однако несколько форков оригинального MySQL с открытым исходным кодом, включая MariaDB и Percona, сняли эти опасения.

Когда использовать MySQL?

Хотя PostgreSQL имеет множество передовых фич и часто считается более продвинутой и сложной системой управления базами данных, чем MySQL, у нее есть свои недостатки.

К общим недостаткам PostgreSQL можно отнести следующие:

  1. Несмотря на свои продвинутые функции и возможности, PostgreSQL еще не достигла того же уровня популярности и широкого использования, что и MySQL. Это привело к меньшему количеству сторонних инструментов, опытных разработчиков и администраторов баз данных в экосистеме PostgreSQL.

  2. Из-за своих расширенных возможностей PostgreSQL может быть сложнее в настройке и управлении, чем MySQL, поэтому она больше подходит для опытных администраторов баз данных и разработчиков.

  3. В некоторых случаях PostgreSQL работает медленнее, чем MySQL, из-за более сложной архитектуры и функций.

  4. PostgreSQL потребляет больше ресурсов, чем MySQL, особенно в плане использования памяти и процессора.

  5. Хотя PostgreSQL поставляется с открытым исходным кодом, стоимость внедрения и обслуживания может быть высокой из-за ее расширенных возможностей и повышенных требований к ресурсам.

  6. PostgreSQL заново запускает еще один процесс для каждого нового клиентского подключения, что приводит к выделению значительного объема памяти, обычно около 10 МБ на соединение. Однако такая архитектура разработана для обеспечения повышенной безопасности и изоляции между различными клиентами и, как правило, считается компромиссом ради повышения производительности, надежности и масштабируемости.

  7. PostgreSQL разработана с учетом приоритетов расширяемости, соответствия стандартам, масштабируемости и целостности данных. Иногда данные фичи могут снижать производительность по сравнению с MySQL, особенно в обычных рабочих нагрузках, связанных с интенсивными операциями чтения. Однако важно отметить, что точное значение разницы в производительности зависит от ряда факторов, таких как размер данных, сложность запросов и используемое оборудование.

Какая миграция более распространена: MySQL на PostgreSQL или PostgreSQL на MySQL?

Частота миграции между MySQL и PostgreSQL различна и зависит от потребностей и требований отдельных организаций. Некоторые организации могут мигрировать с MySQL на PostgreSQL, чтобы воспользоваться ее расширенными возможностями, лучшим соответствием требованиям SQL и совместимостью с открытым исходным кодом. PostgreSQL также более распространена в определенных отраслях, таких как финансовые услуги, государственное управление и хранение данных, где производительность, масштабируемость и безопасность являются важными факторами.

С другой стороны, другие компании могут перейти с PostgreSQL на MySQL из-за ее простоты, широкой поддержки сообщества и более низкой стоимости внедрения.

Согласно различным показателям, миграционный тренд направлен в сторону перехода с MySQL на PostgreSQL. Эти показатели говорят о том, что больше людей переходят с MySQL на PostgreSQL, чем наоборот.

  1. Доступность инструментов миграции: Существует множество бесплатных и коммерческих инструментов миграции, помогающих перенести данные с MySQL на PostgreSQL. При этом инструментов для переноса данных с PostgreSQL на MySQL гораздо меньше.

  2. Онлайн-ресурсы: Существует больше онлайн-учебников и ресурсов по миграции с MySQL на PostgreSQL, чем наоборот.

  3. Рост сообщества: Сообщество PostgreSQL растет быстрее, чем сообщество MySQL, что указывает на повышающийся интерес к использованию PostgreSQL по сравнению с MySQL.

  4. Вложения в открытый исходный код: Увеличивающееся количество вкладов в PostgreSQL с открытым исходным кодом указывает на то, что все больше людей инвестируют время и ресурсы в эту технологию и находят ее полезной для своих нужд.

  5. Внедрение на предприятиях: Некоторые из крупнейших в мире и наиболее требовательных к данным организаций, такие как Cisco, Fujitsu и Федеральная авиационная администрация США (FAA), публично заявили, что перешли с MySQL на PostgreSQL.

  6. Опросы пользователей: Отраслевые аналитики и эксперты по базам данных провели опросы, которые показывают, что все больше людей обдумывают возможность или планируют перейти с MySQL на PostgreSQL.

Эти факты свидетельствуют лишь о том, что с MySQL на PostgreSQL переходят чаще, чем наоборот, и это может быть верно лишь в некоторых случаях.

Заключение

PostgreSQL и MySQL — надежные реляционные системы управления базами данных с уникальными возможностями и ограничениями. Решение об использовании какой‑либо из них должно основываться на конкретных требованиях проекта, таких как характер и объем данных, сложность запросов, а также потребности в производительности и масштабируемости. Поскольку и PostgreSQL, и MySQL в 2023 году ожидает дальнейшее развитие, очень важно быть в курсе их последних разработок.

Кроме того, стоит упомянуть, что такие инструменты, как DBConvert Studio, могут помочь при миграции данных между MySQL и PostgreSQL в любом направлении. Эти инструменты позволяют упростить процесс передачи данных из одной базы данных в другую, что может быть особенно полезно, если вы рассматриваете возможность перехода с одной системы на другую.

Перевод статьи подготовлен в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков». По ссылке ниже вы сможете посмотреть запись бесплатного урока, а также узнать о курсе подробнее.

  • Подробнее о курсе

sql — Журнал недопустимых запросов MySQL

спросил

Изменено 4 года, 5 месяцев назад

Просмотрено 42к раз

Я НЕ ВЫПОЛНЯЮ КОМАНДЫ ИЗ PHP!

Значение log_error MySQL установлено в /var/log/mysql/error. log

Однако, когда я подключаюсь к базе данных и запускаю команду SQL, ошибка не появляется в журнале.

ВЫБИРАТЬ *
ОТ некоторой_таблицы
где this_is_invalid_and_will_fail="Не имеет значения, потому что столбца не существует!";

Есть команды, запущенные из какого-то приложения Windows. Все, что я хочу знать, это то, какие недопустимые команды отправляются на сервер MySQL, чтобы я мог попытаться их разрешить.

  • sql
  • mysql
  • просмотр
  • ведение журнала

Журнал ошибок не делает этого: https://dev.mysql.com/doc/refman/8.0/en/error-log.html

Журнал ошибок содержит информацию указывая, когда mysqld был запущен и остановлено, а также любые критические ошибки которые происходят, когда сервер бег.

MySQL нигде не регистрирует недействительные/неудачные запросы.

Если это для целей отладки, вы можете попробовать настроить прокси-сервер MySQL, который мог бы регистрировать это, я думаю:

http://dev. mysql.com/downloads/mysql-proxy/

4

В принципе, есть 2 способа.

1) настроить какой-нибудь прокси, который может логировать запросы об ошибках. Существует множество форков оригинального прокси-сервера mysql (о котором упоминал @Mchl) — https://github.com/search?utf8=%E2%9C%93&q=MySQL+Proxy. Также вы можете найти последнюю версию оригинальный прокси-сервер mysql здесь https://github.com/mysql/mysql-proxy

Мне не нравится этот способ, потому что он слишком сложен для быстрой отладки

2) вы можете включить общий журнал в mysql (который будет регистрировать ВСЕ запросы). Это создаст большие накладные расходы и не соответствует производственным требованиям, но это быстрый и простой способ исправить ошибки в среде разработки.

Просто войдите в свой mysql и выполните УСТАНОВИТЬ ГЛОБАЛЬНЫЙ general_log = 'ВКЛ'; ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ, КАК 'general_log%';

Вы увидите расположение журналов, например

+------------------+-------------------------+ | Имя_переменной | Значение | +------------------+-------------------------+ | общий_лог | ВЫКЛ | | общий_файл_журнала | /mnt/ssd/mysql/s. log | +------------------+-------------------------+

После этого выполнить mysqladmin сброс-журналы -u root -p

Когда вам нужно будет остановить логи — просто выполните УСТАНОВИТЬ ГЛОБАЛЬНЫЙ general_log = 'ВЫКЛ';

2

Начиная с версии mysql 5.6.3 (выпущенной 3 октября 2011 г.) существует переменная с именем

log-raw , которая позволяет включать недопустимые запросы в общий журнал запросов:

https://dev.mysql .com/doc/refman/5.6/en/server-options.html#option_mysqld_log-raw

Вам необходимо включить общий журнал запросов, используя общий журнал и общий файл журнала , например:

 [mysqld]
общий журнал = 1
лог-сырье = 1
общий файл журнала =/var/log/mysql/general.log
3

Не могли бы вы включить общий журнал запросов? Это должно сказать вам все, что вам нужно знать.

9

Это не так уж и тривиально.

Лучший способ сделать это — регистрировать неправильные запросы в вашем приложении. Нет встроенного способа.

1

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания и подтверждаете, что прочитали и поняли нашу политику конфиденциальности и кодекс поведения.

разрешений — Можете ли вы «су-» в MySQL?

спросил

Изменено 3 года, 6 месяцев назад

Просмотрено 3к раз

Если у меня есть права root в базе данных mysql и я хочу отказаться от привилегий обычного пользователя, не используя его пароль, могу ли я это сделать? если да то как? думаю #su - имя пользователя в unix. По сути, я просто хочу, чтобы их пароль не был им, поэтому я могу проверить их привилегии у их пользователя. В postgres я мог бы просто разрешить аутентификацию ident для пользователя root системы, чтобы обойти аутентификацию по паролю. Причина, по которой мне это нужно, заключается в том, чтобы иметь возможность воспроизвести проблему пользователей, будучи ими, а не быть ими, не позволит точно воспроизвести. Я могу, конечно, попросить их пароль, но это займет больше времени, чем его обход.

  • MySQL
  • разрешения
0

Я только что понял — если вы не против заблокировать пользователя во время входа в систему —

  1. сделайте резервную копию таблицы mysql.user (ну, по крайней мере, хешированного пароля пользователя)
  2. установите их пароль на то, что вы знаете: ОБНОВЛЕНИЕ mysql.user SET password=PASSWORD('новый пароль') WHERE user='username' AND host='hostname';
  3. войдите как они
  4. вернули их пароль к тому, что было: ОБНОВЛЕНИЕ mysql.user SET password='сохраненный хэш пароля' WHERE user='username' AND host='hostname';

… вам может понадобиться сброс привилегий ; после манипулирования таблицей mysql.user.

3

Можно эмулировать пользователя, начиная с MySQL 5.5.7, с введением прокси-пользователей. Я никогда не делал этого раньше, поэтому я попробовал это с помощью тестового плагина аутентификации, так как кажется, что прокси-пользователи работают только с включенными плагинами аутентификации. Вот шаги, которые я предпринял.

Первые шаги от имени пользователя root:

  • mysql> УСТАНОВИТЬ ПЛАГИН test_plugin_server SONAME 'auth_test_plugin.so';

  • mysql> ПОКАЗАТЬ ПЛАГИНЫ;

  • Создать пользователя для эмуляции (в вашем случае он уже существует):

    mysql> ПРЕДОСТАВИТЬ ВСЕ ПРИВИЛЕГИИ НА dtest @ localhost ОПРЕДЕЛЕН 'mypass';

  • Создать пользователя «прокси»:

    mysql> СОЗДАЙТЕ ПОЛЬЗОВАТЕЛЯ proxy@localhost, ИДЕНТИФИЦИРОВАННОГО С помощью test_plugin_server AS 'dtest';

  • mysql> ПРЕДОСТАВИТЬ ПРОКСИ НА dtest@localhost TO proxy@localhost;

  • mysql> FLUSH PRIVILEGES;

Теперь попробуйте войти в систему, используя пользователя: proxy , пароль: dtest (переменная «AS» пользователя прокси):

В настоящее время MySQL не имеет пароля root и вместо этого использует плагин auth_socket чтобы убедиться, что пользователь, подключившийся к сокету, является корневым пользователем системы. Вы можете использовать этот же метод для решения своей проблемы, если у вас все в порядке с учетными записями unix для всех ваших пользователей, что открывает всевозможные возможности, например. простое хранение двоичных файлов!

Сначала вы должны добавить учетную запись unix для пользователя:

root: adduser testuser

Затем добавить соответствующего пользователя MySQL (может быть выполнено автоматически в сценарии adduser.local ):

CREATE USER ' testuser'@'localhost' ИДЕНТИФИЦИРОВАН С auth_socket;

Теперь переключитесь на пользователя (пароль не требуется, если вы делаете это как root):

root: su testuser

Подключитесь к MySQL как пользователь (пароль не требуется, поскольку вы вошли в систему как этот пользователь):

testuser: mysql -u $USER (или -you testuser вместо использования переменной окружения)

Лучше указать пользовательский параметр -u , потому что процедура автоматического удобства пользователя клиента mysql не очень хороша в вычислении это само по себе, например. если вы переходите от пользователя к учетной записи пользователя, по какой-то причине он использует первого пользователя.

Я не знаю конкретного способа воспроизвести эквивалент su , однако вам не нужен их пароль — из-за того, как mysql обрабатывает аутентификацию, вы можете установить другой пароль (или не использовать его в all) с каждой машины, с которой выполнен вход.

5

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания и подтверждаете, что прочитали и поняли нашу политику конфиденциальности и кодекс поведения.

No related posts.