пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Apache Cassandra — это программное обеспечение распределенной базы данных с открытым исходным кодом для работы с базами данных NoSQL. Это программное обеспечение использует язык запросов Cassandra - CQL в качестве основы для связи. CQL хранит данные в таблицах, организованных в виде набора строк со столбцами, содержащими пары ключ-значение.
Таблицы CQL сгруппированы в контейнеры данных, которые в Cassandra называются пространствами ключей (keyspace). Данные, хранящиеся в одном пространстве ключей, не связаны с другими данными в кластере. Таким образом, вы можете иметь таблицы для разных целей в отдельных пространствах ключей в кластере, и данные не будут совпадать.
В этом руководстве вы узнаете, как создать таблицу Cassandra для различных целей, а также как изменять, удалять или очищать таблицы с помощью оболочки Cassandra.
Выбор пространства ключей для таблицы Cassandra
Прежде чем вы начнете добавлять таблицу, вам нужно определить пространство ключей, в котором вы хотите создать свою таблицу. Есть два варианта сделать это.
Вариант 1: команда USE
Запустите команду USE, чтобы выбрать пространство клавиш, к которому будут применяться все ваши команды. Для этого в оболочке cqlsh введите:
USE keyspace_name;
Затем вы можете начать добавлять таблицы.
Вариант 2. Укажите имя пространства ключей в запросе
Второй вариант — указать имя пространства ключей в запросе на создание таблицы. Первая часть команды перед именами столбцов и параметрами выглядит так:
CREATE TABLE keyspace_name.table_name
Таким образом, вы сразу же создаете таблицу в заданном пространстве ключей.
Базовый синтаксис для создания таблиц Cassandra
Создание таблиц с помощью CQL похоже на SQL-запросы. В этом разделе мы покажем вам основной синтаксис для создания таблиц в Cassandra.
Основной синтаксис для создания таблицы выглядит следующим образом:
CREATE TABLE tableName (
columnName1 dataType,
columnName2 dataType,
columnName2 datatype
PRIMARY KEY (columnName)
);
При желании вы можете определить дополнительные свойства и значения таблицы, используя WITH:
WITH propertyName=propertyValue;
Например, используйте его, чтобы определить, как хранить данные на диске или использовать ли сжатие.
Типы первичных ключей Cassandra
Каждая таблица в Cassandra должна иметь первичный ключ, что делает строку уникальной. С первичными ключами вы определяете, какой узел хранит данные и как он их разделяет.
Существует несколько типов первичных ключей:
Простой первичный ключ. Содержит только одно имя столбца в качестве ключа секции, чтобы определить, какие узлы будут хранить данные.
Составной первичный ключ. Использует один ключ разделения и несколько столбцов кластеризации, чтобы определить, где хранить данные и как их сортировать в разделе.
Составной ключ раздела. В этом случае есть несколько столбцов, которые определяют, где хранить данные. Таким образом, вы можете разбить данные на более мелкие части, чтобы распределить их по нескольким разделам, чтобы избежать горячих точек.
Как создать таблицу Cassandra
В следующих разделах объясняется, как создавать таблицы с различными типами первичных ключей. Сначала выберите пространство ключей, в котором вы хотите создать таблицу. В нашем случае:
USE businesinfo;
Каждая таблица содержит столбцы и тип данных Cassandra для каждой записи.
Создать таблицу с простым первичным ключом
Первый пример — это базовая таблица с поставщиками. Идентификатор уникален для каждого поставщика и будет служить первичным ключом.
CQL-запрос выглядит следующим образом:
CREATE TABLE suppliers (
supp_id int PRIMARY KEY,
supp_city text,
supp_email text,
supp_fee int,
supp_name text,
supp_phone int
);
Этот запрос создал таблицу с именем supplier с supp_id в качестве первичного ключа для таблицы. Когда вы используете простой первичный ключ с именем столбца в качестве ключа раздела, вы можете поместить его либо в начало запроса (рядом со столбцом, который будет служить первичным ключом), либо в конец, а затем указать имя столбца:
CREATE TABLE suppliers (
supp_id int,
supp_city text,
supp_email text,
supp_fee int,
supp_name text,
supp_phone int
PRIMARY KEY(supp_id)
);
Чтобы увидеть, находится ли таблица в пространстве ключей, введите:
DESCRIBE TABLES;
В выводе перечислены все таблицы в этом пространстве ключей, а также та, которую вы создали.
Чтобы отобразить содержимое таблиц, введите:
SELECT * FROM suppliers;
Вывод показывает все столбцы, определенные при создании таблицы.
Другой способ просмотреть сведения о таблице — использовать DESCRIBE и указать имя таблицы:
DESCRIBE suppliers;
В выходных данных отображаются столбцы и настройки по умолчанию для таблицы.
Создать таблицу с составным первичным ключом
Чтобы запросить и получить результаты, отсортированные в определенном порядке, создайте таблицу с составным первичным ключом.
Например, создайте таблицу для поставщиков и всех продуктов, которые они предлагают. Поскольку продукты могут не быть уникальными для каждого поставщика, необходимо добавить один или несколько столбцов кластеризации в первичный ключ, чтобы сделать его уникальным.
Схема таблицы выглядит так:
CREATE TABLE suppliers_by_product (
supp_product text,
supp_id int,
supp_product_quantity text,
PRIMARY KEY(supp_product, supp_id)
);
В этом случае мы использовали supp_product и supp_id для создания уникального составного ключа. Здесь первая запись в скобках supp_product — это ключ раздела. Он определяет, где хранить данные, то есть как система разделяет данные.
Следующая запись — столбец кластеризации, определяющий, как Cassandra сортирует данные, в нашем случае — по supp_id.
Изображение выше показывает, что таблица была успешно создана. Чтобы проверить детали таблицы, запустите запрос DESCRIBE TABLE для новой таблицы:
DESCRIBE TABLE suppliers_by_product;
Настройки по умолчанию для порядка кластеризации — по возрастанию (ASC). Вы можете перейти на нисходящий (DESC), добавив следующий оператор после первичного ключа:
WITH CLUSTERING ORDER BY (supp_id DESC);
Мы указали один столбец кластеризации после ключа раздела. Если вам нужно отсортировать данные с использованием двух столбцов, добавьте еще один столбец в скобки первичного ключа.
Создание таблиц с использованием составного ключа раздела
Создание таблицы с составным ключом раздела полезно, когда на одном узле хранится большой объем данных, и вы хотите разделить нагрузку на несколько узлов.
В этом случае определите первичный ключ с ключом секции, состоящим из нескольких столбцов. Вам нужно использовать двойные скобки. Затем добавьте столбцы кластеризации, как мы делали ранее, чтобы создать уникальный первичный ключ.
CREATE TABLE suppliers_by_product_type (
supp_product_consume text,
supp_product_stock text,
supp_id int,
supp_name text,
PRIMARY KEY((supp_product_consume, supp_product_stock), supp_id)
);
В приведенном выше примере мы разделили данные на две категории: расходные материалы поставщика и продукты, запасаемые на складе, и распределили данные с помощью составного ключа раздела.
Примечание. При таком разделении каждая категория продуктов хранится на отдельном узле, а не в одном разделе.
Если вместо этого вы используете составной первичный ключ с простым ключом раздела и несколькими столбцами кластеризации, то один узел будет обрабатывать все данные, отсортированные по нескольким столбцам.
Удалить таблицу в Cassandra
Чтобы удалить таблицу в Cassandra, используйте оператор DROP TABLE. Чтобы выбрать таблицу, которую вы хотите удалить, введите:
DESCRIBE TABLES;
Найдите таблицу, которую хотите удалить. Используйте имя таблицы, чтобы удалить ее:
DROP TABLE suppliers_by_product_type;
Запустите запрос DESCRIBE TABLES еще раз, чтобы убедиться, что вы успешно удалили таблицу.
Изменить таблицу в Cassandra
Cassandra CQL позволяет добавлять или удалять столбцы из таблицы. Используйте команду ALTER TABLE, чтобы внести изменения в таблицу.
Добавить столбец в таблицу
Перед добавлением столбца в таблицу рекомендуется просмотреть содержимое таблицы, чтобы убедиться, что имя столбца еще не существует.
После проверки используйте запрос ALTER TABLE в этом формате, чтобы добавить столбец:
ALTER TABLE suppliers_by_product
ADD supp_name text;
Снова используйте DESCRIBE TABLE, чтобы убедиться, что столбец появился в списке.
Удалить столбец из таблицы
Подобно добавлению столбца, вы можете удалить столбец из таблицы. Найдите столбец, который вы хотите удалить, с помощью запроса DESCRIBE TABLES.
Затем введите:
ALTER TABLE suppliers_by_product
DROP supp_product_quantity;
Примечание. Не указывайте тип данных для столбца, если вы хотите удалить его из таблицы. Вы получите ошибку “SyntaxException: line 1:48 mismatched input ‘text’ expecting EOF (ALTER TABLE suppliers_by_product DROP supp_name [text]…)”
Очистить таблицу в Cassandra
Если вы не хотите удалять всю таблицу, но вам нужно удалить все строки, используйте команду TRUNCATE.
Например, чтобы удалить все строки из таблицы поставщиков, введите:
TRUNCATE suppliers;
Чтобы убедиться, что в вашей таблице больше нет строк, используйте оператор SELECT.
После очистки таблицы изменения становятся постоянными, поэтому будьте осторожны при использовании этого запроса.
Итоги
В этом руководстве показано, как создавать таблицы в Cassandra для различных целей с использованием простых и составных первичных ключей. Примеры также включали использование составного ключа раздела для распределения данных по узлам.
Мы также рассмотрели, как вы можете удалять, изменять и очищать таблицы в Cassandra. Убедитесь, что вы удаляете или вносите изменения в правильные таблицы, чтобы избежать потенциальных проблем.
Первая часть тут
Как только изменение в топологии сети было обнаружено, оно должно быть каким-то образом распределено по всем устройствам, участвующим в плоскости управления. Каждый элемент в топологии сети может быть описан как:
Канал или граница, включая узлы или достижимые места назначения, прикрепленные к этому каналу.
Устройство или узел, включая узлы, каналы и доступные места назначения, подключенные к этому устройству.
Этот довольно ограниченный набор терминов может быть помещен в таблицу или базу данных, часто называемую таблицей топологии или базой данных топологии. Таким образом, вопрос о распределении изменений в топологии сети на все устройства, участвующие в плоскости управления, можно описать как процесс распределения изменений в определенных строках в этой таблице или базе данных по всей сети.
Способ, которым информация распространяется по сети, конечно, зависит от конструкции протокола, но обычно используются три вида распространения: поэтапное (hop-by-hop) распространение, лавинное (flooded) распространение и централизованное (centralized) хранилище некоторого вида.
Лавинное (flooded) распространение.
При лавинной рассылке каждое устройство, участвующее в плоскости управления, получает и сохраняет копию каждой части информации о топологии сети и доступных местах назначения. Хотя существует несколько способов синхронизации базы данных или таблицы, в плоскостях управления обычно используется только один: репликация на уровне записи. Рисунок 6 иллюстрирует это.
На рисунке 6 каждое устройство будет рассылать известную ему информацию ближайшим соседям, которые затем повторно рассылают информацию своим ближайшим соседу. Например, A знает две специфические вещи о топологии сети: как достичь 2001: db8: 3e8: 100 :: / 64 и как достичь B. A передает эту информацию в B, который, в свою очередь, передает эту информацию в C. Каждое устройство в сети в конечном итоге получает копию всей доступной топологической информации; A, B и C имеют синхронизированные базы данных топологии (или таблицы).
На рисунке 6 связь C с D показана как элемент в базе данных. Не все плоскости управления будут включать эту информацию. Вместо этого C может просто включать подключение к диапазону адресов 2001: db8: 3e8: 102 :: / 64 (или подсети), который содержит адрес D.
Примечание. В более крупных сетях невозможно уместить все описание подключений устройства в один пакет размером с MTU, и для обеспечения актуальности информации о подключении необходимо регулярно задерживать время ожидания и повторно загружать данные.
Интересная проблема возникает в механизмах распространения Flooding рассылки, которые могут вызывать временные петли маршрутизации, называемые microloops. Рисунок 7 демонстрирует эту ситуацию. На рисунке 7, предположим, что канал [E, D] не работает. Рассмотрим следующую цепочку событий, включая примерное время для каждого события:
Старт: A использует E, чтобы добраться до D; C использует D, чтобы добраться до E.
100 мс: E и D обнаруживают сбой связи.
500 мс: E и D рассылают информацию об изменении топологии на C и A.
750 мс: C и A получают обновленную информацию о топологии.
1000 мс: E и D пересчитывают свои лучшие пути; E выбирает A как лучший путь для достижения D, D выбирает C как лучший путь для достижения E.
1,250 мс: лавинная рассылка A и C информации об изменении топологии на B.
1400 мс: A и C пересчитывают свои лучшие пути; A выбирает B для достижения D, C выбирает B для достижения E.
1500 мс: B получает обновленную информацию о топологии.
2,000 мс: B пересчитывает свои лучшие пути; он выбирает C, чтобы достичь D, и A, чтобы достичь E.
Хотя время и порядок могут незначительно отличаться в каждой конкретной сети, порядок обнаружения, объявления и повторных вычислений почти всегда будет следовать аналогичной схеме. В этом примере между этапами 5 и 7 образуется микропетля; в течение 400 мс, A использует E для достижения D, а E использует A для достижения D. Любой трафик, входящий в кольцо в A или D в течение времени между пересчетом E лучшего пути к D и пересчетом A лучшего пути к D будет петлей. Одним из решений этой проблемы является предварительное вычисление альтернативных вариантов без петель или удаленных альтернатив без петель.
Hop by Hop
При поэтапном распределении каждое устройство вычисляет локальный лучший путь и отправляет только лучший путь своим соседям. Рисунок 8 демонстрирует это.
На рисунке 8 каждое устройство объявляет информацию о том, что может достигнуть каждого из своих соседей. D, например, объявляет о достижимости для E, а B объявляет о доступности для C, D и E для A. Интересно рассмотреть, что происходит, когда A объявляет о своей доступности для E через канал на вершине сети. Как только E получит эту информацию, у него будет два пути к B, например: один через D и один через A. Таким же образом у A будет два пути к B: один напрямую к B, а другой через E. Любой из алгоритмов кратчайшего пути, рассмотренные в предыдущих статьях, могут определить, какой из этих путей использовать, но возможно ли формирование микропетель с помощью лавинного механизма распределения?
Рассмотрим:
E выбирает путь через A, чтобы добраться до B.
Канал [A, B] не работает.
A обнаруживает этот сбой и переключается на путь через E.
Затем A объявляет этот новый путь к E.
E получает информацию об измененной топологии и вычисляет новый лучший путь через D.
В промежутке между шагами 3 и 5 А будет указывать на Е как на свой лучший путь к В, в то время как Е будет указывать на А как на свой лучший путь к В—микропетля. Большинство распределительных систем hop-by-hop решают эту проблему с помощью split horizon или poison reverse.
Определены они следующим образом:
Правило split horizon гласит: устройство не должно объявлять о доступности к пункту назначения, который он использует для достижения пункта назначения.
Правило poison reverse гласит: устройство должно объявлять пункты назначения по отношению к соседнему устройству, которое оно использует, чтобы достичь пункта назначения с бесконечной метрикой.
Если разделение горизонта (split horizon) реализованный на рисунке 8, E не будет объявлять о достижимости для B, поскольку он использует путь через A для достижения B. В качестве альтернативы E может отравить путь к B через A, что приведет к тому, что A не будет иметь пути через E к B.
Централизованное Хранилище.
В централизованной системе каждое сетевое устройство сообщает информацию об изменениях топологии и достижимости контроллеру или, скорее, некоторому набору автономных служб и устройств, действующих в качестве контроллера. В то время как централизация часто вызывает идею единого устройства (или виртуального устройства), которому передается вся информация и который передает правильную информацию для пересылки всем устройствам обработки пакетов в сети, это чрезмерное упрощение того, что на самом деле означает централизованная плоскость управления. Рисунок 9 демонстрирует это.
На рисунке 9, когда канл между D и F не работает:
D и F сообщают об изменении топологии контроллеру Y.
Y пересылает эту информацию другому контроллеру X.
Y вычисляет лучший путь к каждому месту назначения без канала [D, F] и отправляет его каждому затронутому устройству в сети.
Каждое устройство устанавливает эту новую информацию о пересылке в свою локальную таблицу.
Конкретный пример шага 3 - Y вычисляет следующий лучший путь к E без канала [D, F] и отправляет его D для установки в его локальной таблице пересылки. Могут ли микропетли образовываться в централизованной плоскости управления?
Базы данных в X и Y должны быть синхронизированы, чтобы оба контроллера вычисляли одинаковые пути без петель в сети
Синхронизация этих баз данных повлечет за собой те же проблемы и (возможно) использование тех же решений, что и решения, обсуждавшиеся до сих пор в этой статье.
Подключенным устройствам потребуется некоторое время, чтобы обнаружить изменение топологии и сообщить об этом контроллеру.
Контроллеру потребуется некоторое время, чтобы вычислить новые пути без петель.
Контроллеру потребуется некоторое время, чтобы уведомить затронутые устройства о новых путях без петель в сети.
Во время временных интервалов, описанных здесь, сеть все еще может образовывать микропетли. Централизованная плоскость управления чаще всего переводится в плоскость управления не запущенными устройствами переадресации трафика. Хотя они могут казаться радикально разными, централизованные плоскости управления на самом деле используют многие из тех же механизмов для распределения топологии и достижимости, а также те же алгоритмы для вычисления безцикловых путей через сеть, что и распределенные плоскости управления.
Плоскости сегментирования и управления.
Одна интересная идея для уменьшения состояния, переносимого на любое отдельное устройство, независимо от того, используется ли распределенная или централизованная плоскость управления, заключается в сегментировании информации в таблице топологии (или базе данных). Сегментация-это разделение информации в одной таблице на основе некоторого свойства самих данных и хранение каждого полученного фрагмента или фрагмента базы данных на отдельном устройстве. Рисунок 10 демонстрирует это.
В сети на рисунке 10 предположим, что оба контроллера, X и Y, имеют информацию о топологии для всех узлов (устройств) и ребер (каналов) в сети. Однако для масштабирования размера сети доступные места назначения были разделены на два контроллера. Существует множество возможных схем сегментирования - все, что может разделить базу данных (или таблицу) на части примерно одинакового размера, будет работать. Часто используется хеш, так как хеши можно быстро изменить на каждом устройстве, где хранится сегмент, чтобы сбалансировать размеры сегментов.
В этом случае предположим, что схема сегментирования немного проще: это диапазон IP-адресов. В частности, на рисунке представлены два диапазона IP-адресов: 2001: db8: 3e8: 100 :: / 60, который содержит от 100 :: / 64 до 10f :: / 64; и 2001: db8: 3e8: 110 :: / 60, который содержит от 110 :: / 64 до 11f :: / 64. Каждый из этих диапазонов адресов разделен на один контроллер; X будет содержать информацию о 2001: db8: 3e8: 100 :: / 60, а Y будет содержать информацию о 2001: db8: 3e8: 110 :: / 64. Не имеет значения, где эти доступные пункты назначения подключены к сети. Например, информация о том, что 2001: db8: 3e8: 102 :: / 64 подключен к F, будет храниться в контроллере X, а информация о том, что 2001: db8: 3e8: 110 :: / 64 подключен к A, будет храниться на контроллере Y. Чтобы получить информацию о доступности для 2001: db8: 3e8: 102 :: / 64, Y потребуется получить информацию о том, где этот пункт назначения соединен с X. Это будет менее эффективно с точки зрения вычисления кратчайших путей, но он будет более эффективным с точки зрения хранения информации, необходимой для вычисления кратчайших путей. Фактически, возможно, если информация хранится правильно (а не тривиальным способом, используемым в этом примере), чтобы несколько устройств вычислили разные части кратчайшего пути, а затем обменивались только результирующим деревом друг с другом. Это распределяет не только хранилище, но и обработку.
Существует несколько способов, с помощью которых информация о плоскости управления может быть разделена, сохранена и, когда вычисления выполняются через нее, чтобы найти набор путей без петель через сеть.
Согласованность, доступность и возможность разделения.
Во всех трех системах распределения, обсуждаемых в этой статье, - лавинной, поэтапной и централизованных хранилищ - возникает проблема микропетель. Протоколы, реализующие эти методы, имеют различные системы, такие как разделение горизонта и альтернативы без петель, чтобы обходить эти микропетли, или они позволяют микропетлям появляться, предполагая, что последствия будут небольшими для сети. Существует ли объединяющая теория или модель, которая позволит инженерам понять проблемы, связанные с распределением данных по сети, и различные сопутствующие компромиссы?
Есть: теорема CAP.
В 2000 году Эрик Брюер, занимаясь как теоретическими, так и практическими исследованиями, постулировал, что распределенная база данных обладает тремя качествами: Согласованностью, Доступностью и устойчивость к разделению (Consistency, Accessibility Partition tolerance-CAP). Между этими тремя качествами всегда есть компромисс, так что вы можете выбрать два из трех в любой структуре системы. Эта гипотеза, позже доказанная математически, теперь известна как теорема CAP. Эти три термина определяются как:
Согласованность: Каждый считыватель видит согласованное представление содержимого базы данных. Если какое-то устройство С записывает данные в базу данных за несколько мгновений до того, как два других устройства, А и В, прочитают данные из базы данных, оба считывателя получат одну и ту же информацию. Другими словами, нет никакой задержки между записью базы данных и тем, что оба считывателя, А и В, могут прочитать только что записанную информацию.
Доступность: каждый считыватель имеет доступ к базе данных при необходимости (почти в реальном времени). Ответ на чтение может быть отложен, но каждое чтение будет получать ответ. Другими словами, каждый считыватель всегда имеет доступ к базе данных. Не существует времени, в течение которого считыватель получил бы ответ «сейчас вы не можете запросить эту базу данных».
Устойчивость к разделению: возможность копирования или разделения базы данных на несколько устройств.
Проще изучить теорему CAP в небольшой сети. Для этого используется рисунок 11.
Предположим, что A содержит единственную копию базы данных, к которой должны иметь доступ как C, так и D. Предположим, что C записывает некоторую информацию в базу данных, а затем сразу же после, C и D считывают одну и ту же информацию. Единственная обработка, которая должна быть, чтобы убедиться, что C и D получают одну и ту же информацию, - это A. Теперь реплицируйте базу данных, чтобы была копия на E и еще одна копия на F. Теперь предположим, что K записывает в реплику на E, а L читает из реплики на F. Что же будет?
F может вернуть текущее значение, даже если это не то же самое значение, что только что записал К. Это означает, что база данных возвращает непоследовательный ответ, поэтому согласованность была принесена в жертву разделению базы данных.
Если две базы данных синхронизированы, ответ, конечно, в конечном итоге одинаковым, но потребуется некоторое время, чтобы упаковать изменение (упорядочить данные), передать его в F и интегрировать изменение в локальную копию F. F может заблокировать базу данных или определенную часть базы данных, пока выполняется синхронизация. В этом случае, когда L читает данные, он может получить ответ, что запись заблокирована. В этом случае доступность теряется, но сохраняется согласованность и разбиение базы данных.
Если две базы данных объединены, то согласованность и доступность могут быть сохранены за счет разделения.
Невозможно решить эту проблему, чтобы все три качества были сохранены, из-за времени, необходимого для синхронизации информации между двумя копиями базы данных. Та же проблема актуальна и для сегментированной базы данных.
Как это применимо к плоскости управления? В распределенной плоскости управления база данных, из которой плоскость управления черпает информацию для расчета путей без петель, разделена по всей сети. Кроме того, база данных доступна для чтения локально в любое время для расчета путей без петель. Учитывая разделение и доступность, необходимые для распределенной базы данных, используемой в плоскости управления, следует ожидать, что непротиворечивость пострадает - и это действительно так, что приводит к микропетлям во время конвергенции. Централизованная плоскость управления не «решает» эту проблему. Централизованная плоскость управления, работающая на одном устройстве, всегда будет согласованной, но не всегда будет доступной, а отсутствие разделения будет представлять проблему для устойчивости сети.
Не все любят управлять MySQL через Linux. Management Studio – говорили они. CLI – говорим мы. Бро, эта статья про то, как дать права доступа (permissions) учетным записям в Linux – среде.
Логинимся
Подключаемся к своему серверу по SSH. В командной строке вводим:
mysql -u root -p
Хоп – и мы уже в режиме управления MySQL:
mysql>
Вообще, эта статья про права доступа. Но на всякий случай вот тебе синтаксис команды, которая позволит создать нового пользователя с паролем в MySQL:
CREATE USER 'логин'@'localhost' IDENTIFIED BY 'пароль';
А теперь права
Друже, синтаксис команды, которая даст нужные тебе права крайне простой. Вот он:
GRANT права ON база_данных.таблица TO 'логин'@'localhost';
Разберемся слева на право:
права - могут быть следующие:
ALL – дает полный доступ к базе данных. Кстати, если база данных не определена в команде, то даст полный доступ ко всему в MySQL (ох не надо так);
CREATE – позволяет пользователю создавать базы данных и таблицы;
DELETE – дает право пользователю удалять строки из таблиц;
DROP – дает право удалять базы данных и таблица целиком (ну, так тоже не надо);
EXECUTE – дает право пользователю выполнять хранимые процедуры;
GRANT OPTION – с этой опцией юзер сможет давать права (или удалять) другим пользователям;
INSERT – дает право хранить молчанию и все что он скажет будет.. Ладно, это просто право на добавление новых строк в таблицу;
SELECT – самое распространенное право – парсить (извлекать) данные из SQL для чтения;
SHOW DATABASES - этому пользователю можно будет смотреть на список баз данных;
UPDATE – дает право пользователю изменять текущие строки в таблице;
база_данных собственно, база данных, внутри которой живет ваша таблица;
таблица - сама таблица. Табличка, table, le tableau;
логин - имя пользователя вашего юзверя;
Все просто. Пробежимся по примерам.
Пример №1
Давайте дадим права юзеру example, с помощью которых он сможет создавать любые БД и таблицы:
GRANT CREATE ON *.* TO 'example'@'localhost';
Использование звездочки (*) – это как маска, под которое попадает все.
Пример №2
Дадим пользователю example права на удаление любых таблиц в заранее обозначенной базе данных, которая называется easybro
GRANT DROP ON easybro.* TO 'example'@'localhost';
Как видишь, мы юзаем команду DROP. Кстати, лучшая практика после внесения изменения сделать небольшую перезагрузку прав командой:
FLUSH PRIVILEGES;
Как посмотреть права определенного пользователя в MySQL
Посмотреть права очень просто. Опять же, на примере нашего юзера example:
SHOW GRANTS FOR 'example'@'localhost';