Что бы на момент создания дампа не произошло коллизии (дамп снять когда x=1, пока снимаешь x переписали на 2). Реплика работает считая что изначальные данные одинаковы (ну ка считает, ей пофигу, ошибки могут немного тебе жизнь попортить)

Благодарю за ответ! А то немного не вкурил как оно работает. Я думал оно потом само все отзеркалит как в галерном кластере.

Можно ли через код в Питоне следить за новыми добавленными строками в базе? Я знаю, что есть триггеры, это можно через PyMySQL организовать?

Небольшой вопрос по индексам. Как я понял, при создании индекста данные из БД начинают храниться в отсортированном виде (если не так, то поправьте меня). Но если я создам два индекса для таблицы (по одному на колонку), то все файлы буду храниться в отсортированном виде и по одной колонке, и по другой. Как такое возможно?

Небольшой вопрос по индексам. Как я понял, при создании индекста данные из БД начинают храниться в отсортированном виде (если не так, то поправьте меня). Но если я создам два индекса для таблицы (по одному на колонку), то все файлы буду храниться в отсортированном виде и по одной колонке, и по другой. Как такое возможно?

индексы хранятся отдельно от таблицы, они не влияют на сортировку внутри неё, они используются только в момент, когда этот индекс может дать ускорение.

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

Можно ли через код в Питоне следить за новыми добавленными строками в базе? Я знаю, что есть триггеры, это можно через PyMySQL организовать?

такая штука называется CDC. статья на тему: https://www.percona.com/blog/2016/09/13/mysql-cdc-streaming-binary-logs-and-asynchronous-triggers/

Небольшой вопрос по индексам. Как я понял, при создании индекста данные из БД начинают храниться в отсортированном виде (если не так, то поправьте меня). Но если я создам два индекса для таблицы (по одному на колонку), то все файлы буду храниться в отсортированном виде и по одной колонке, и по другой. Как такое возможно?

в индексе в остортированном виде хранятся только значения колонок, которые участвуют в индексе. но в InnoDB есть особенность — primary key кластеризованный, т.е. данные хранятся вместе с отсортированными индексными значениями, и по сути в InnoDB данные всегда отсортированы по первичному ключу

такая штука называется CDC. статья на тему: https://www.percona.com/blog/2016/09/13/mysql-cdc-streaming-binary-logs-and-asynchronous-triggers/

Благодарю.

в индексе в остортированном виде хранятся только значения колонок, которые участвуют в индексе. но в InnoDB есть особенность — primary key кластеризованный, т.е. данные хранятся вместе с отсортированными индексными значениями, и по сути в InnoDB данные всегда отсортированы по первичному ключу

Понял. Спасибо!

Hello everybody, i wish all of us a productiv and iluminated work week ??

Разбираюсь с mysql заметил такую ерунду что по умолчанию каким макаром удаленно можно подрубится к базе (у учетки соотвествующий ip) по netstat не слушает ipv4 но слушает ipv6 я удаленно подключаюсь с указанием ipv4 адреса и опа соединение проходит клинтская машина линукс серверная линукс что за ерунда?

при этом в нетстае соединение по ipv4

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

или ты сам админишь эту машину с самого начала ?

[root@serv ~]# netstat -nlp | grep 3306 tcp6 0 0 :::3306 :::* LISTEN 2375/mysqld при этом ipv4 соединения идут

это таое я в ubuntu тоже замечал

tcp 0 0 192.168.108.129:50988 10.0.XXX.XXX:3306 ESTABLISHED

в bind address пропишешь ип и будет по v4 показывать

забиндить да можно, но хотелось бы выйснить почему так это срабатывает

даже если v6 отключишь все равно будет так показывать

забиндить да можно, но хотелось бы выйснить почему так это срабатывает

а вот это читали? https://dev.mysql.com/doc/refman/5.7/en/ipv6-server-config.html

а вот это читали? https://dev.mysql.com/doc/refman/5.7/en/ipv6-server-config.html

Благодарю. получается что ipv6 слушает и ipv4 выходит по умолчанию

Благодарю. получается что ipv6 слушает и ipv4 выходит по умолчанию

нет, на самом деле, tcp6 0 0 :::3306 не означает "слушает только по IPv6". оно означает "слушает на любом IPv4 и IPv6 интерфейсе". чтобы это ограничить только для IPv6, нужно укзать bind-address=::

это из спецификации IPv6 следует: https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses

Привет

После отключения света база не стартует

[root@localhost ~]# systemctl status mysql ● mariadb.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/mariadb.service.d └─migrated-from-my.cnf-settings.conf Active: failed (Result: exit-code) since Tue 2018-02-13 12:26:48 MSK; 15min ago Process: 25834 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 25972 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE) Process: 25960 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS) Process: 25958 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Main PID: 25972 (code=exited, status=1/FAILURE) Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7173560832 Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178803712 Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178931111 Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Database was not shutdown normally! Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Starting crash recovery. Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Recovered page [page id: space=0, page number=0] from the doublewrite buffer. Feb 13 12:26:48 localhost.localdomain systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE Feb 13 12:26:48 localhost.localdomain systemd[1]: Failed to start MariaDB database server. Feb 13 12:26:48 localhost.localdomain systemd[1]: Unit mariadb.service entered failed state. Feb 13 12:26:48 localhost.localdomain systemd[1]: mariadb.service failed. [root@localhost ~]# journalctl -f -u mariadb.service -- Logs begin at Mon 2018-02-12 10:57:29 MSK. -- Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7173560832 Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178803712 Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178931111 Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Database was not shutdown normally! Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Starting crash recovery. Feb 13 12:26:48 localhost.localdomain mysqld[25972]: 2018-02-13 12:26:48 140614920276160 [Note] InnoDB: Recovered page [page id: space=0, page number=0] from the doublewrite buffer. Feb 13 12:26:48 localhost.localdomain systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE Feb 13 12:26:48 localhost.localdomain systemd[1]: Failed to start MariaDB database server. Feb 13 12:26:48 localhost.localdomain systemd[1]: Unit mariadb.service entered failed state. Feb 13 12:26:48 localhost.localdomain systemd[1]: mariadb.service failed.

Подскажите как можно решить проблему?

Подскажите как можно решить проблему?

в этом логе ничего фатального не вижу. надо смотреть собственный лог mysqld. обычно /var/log/mysql/error.log

По указанному адресу пусто

значит нужно найти, где лежит error log. может в конфиге другое значение. может mariadb по умолчанию в /var/log/mariadb/error.log пишет. может быть в syslog всё пишется. поищите, не сочтите за труд

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

значит нужно найти, где лежит error log. может в конфиге другое значение. может mariadb по умолчанию в /var/log/mariadb/error.log пишет. может быть в syslog всё пишется. поищите, не сочтите за труд

Прошу прощения. Я конечно же пытался его найти.

по пути /etc/my.cnf.d/server.cnf

Нет ничего про сохранение логов

Добавил в файл строки

#General Query Log general_log general_log_file = /var/log/mariadb/mysql_query.log #Error Log log_error = /var/log/mariadb/mysql_error.log

логи так и не появились

мда, systemd конечно убрал бардака в одном, но добавил в другом...

а попробуйте без systemd запустить из консоли /usr/sbin/mysqld --defaults-file=/etc/my.cnf.d/server.cnf --log-error=

чтобы оно туда же в консоль сыпала сообщениями

[root@localhost ~]# /usr/sbin/mysqld --defaults-file=/etc/my.cnf.d/server.cnf --log-error= 2018-02-13 13:57:25 140373909588160 [Note] /usr/sbin/mysqld (mysqld 10.2.3-MariaDB) starting as process 27262 ... 2018-02-13 13:57:25 140373909588160 [ERROR] Fatal error: Please consult the Knowledge Base to find out how to run mysqld as root! 2018-02-13 13:57:25 140373909588160 [ERROR] Aborting [root@localhost ~]#

есть вероятность, что повредилась база данных и восстановление не прошло успешно

На сколько это вероятно

[root@localhost ~]# /usr/sbin/mysqld --defaults-file=/etc/my.cnf.d/server.cnf --log-error= 2018-02-13 13:57:25 140373909588160 [Note] /usr/sbin/mysqld (mysqld 10.2.3-MariaDB) starting as process 27262 ... 2018-02-13 13:57:25 140373909588160 [ERROR] Fatal error: Please consult the Knowledge Base to find out how to run mysqld as root! 2018-02-13 13:57:25 140373909588160 [ERROR] Aborting [root@localhost ~]#

прошу прощения, вот так нужно: /usr/bin/mysqld --defaults-file=/etc/my.cnf.d/server.cnf --user=mysql --skip-log-error

[root@localhost ~]# /usr/bin/mysqld --defaults-file=/etc/my.cnf.d/server.cnf --user=mysql --skip-log-error -bash: /usr/bin/mysqld: No such file or directory

/usr/sbin конечно

[root@localhost ~]# /usr/sbin/mysqld --defaults-file=/etc/my.cnf.d/server.cnf --user=mysql --skip-log-error 2018-02-13 14:06:47 140712006453440 [Note] /usr/sbin/mysqld (mysqld 10.2.3-MariaDB) starting as process 27399 ... 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: PUNCH HOLE support available 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Uses event mutexes 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Compressed tables use zlib 1.2.7 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Using Linux native AIO 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Number of pools: 1 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Using SSE2 crc32 instructions 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Completed initialization of buffer pool 2018-02-13 14:06:47 140710963533568 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Tablespace ID 0 name innodb_system:Default tablespace encryption mode scheme unencrypted 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Highest supported file format is Barracuda. 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Log scan progressed past the checkpoint lsn 7165762539 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7171004928 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7176247808 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178931111 2018-02-13 14:06:47 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7168317952 2018-02-13 14:06:48 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7173560832 2018-02-13 14:06:48 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178803712 2018-02-13 14:06:48 140712006453440 [Note] InnoDB: Doing recovery: scanned up to log sequence number 7178931111 2018-02-13 14:06:48 140712006453440 [Note] InnoDB: Database was not shutdown normally! 2018-02-13 14:06:48 140712006453440 [Note] InnoDB: Starting crash recovery. 2018-02-13 14:06:48 140712006453440 [Note] InnoDB: Recovered page [page id: space=0, page number=0] from the doublewrite buffer. 2018-02-13 14:06:48 140712006453440 [ERROR] InnoDB: Trying to access page number 25297177 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384, i/o type read. If you get this error at mysqld startup, please check that your my.cnf matches the ibdata files that you have in the MySQL server. 2018-02-13 14:06:48 140712006453440 [ERROR] InnoDB: Server exits.

во, это уже что-то

ну судя по всему да, нужно поднимать бэкапы ? а какой размер у /var/lib/mariadb/ibdata1?

у /var/lib/mysql/ibdata1 140 mb

вот, а оно хочет, чтобы оно было 386 gb

то есть, это по-любому data corruption. почему именно — сложный вопрос, зависит от настроек innodb, файловой системы и железа. что делать — поднимать бэкапы, если есть. Можно заморочиться восстановлением данных, но это долгая песня, забесплатно в чатике этим никто не будет заниматься

В каком месте там про 386 gb? База никогда больше 1 гигабайта не весила

В каком месте там про 386 gb? База никогда больше 1 гигабайта не весила

page number 25297177. каждая страница — 16 KB

возможно в заголовке мусор. а может и действительно ibdata1 был когда-то большим, хоть и база весила 1 гиг. undo логи, фрагментация, вот это всё

я вижу, что у вас buffer pool дефолтный, 128M. что уже намекает, что база не особо грамотно администрировалась. поэтому я бы тут никаких вариантов не исключал

всем привет, хочу в отдельной таблице хранить логи выполняемых действий логироватся будут ряд сущьностей (товар, заказ, склад,.....) одно из полей тип сущьности вот делема перечень типов выносить в отдельную таблицу, или сделать ENUM ?

всем привет, хочу в отдельной таблице хранить логи выполняемых действий логироватся будут ряд сущьностей (товар, заказ, склад,.....) одно из полей тип сущьности вот делема перечень типов выносить в отдельную таблицу, или сделать ENUM ?

лучше в отдельную. вдруг тебе надо будет расширить количество

а что мне мешает дополнить перечень ENUM ?

говно практика. ну тут уже ответят спецы лучше.

page number 25297177. каждая страница — 16 KB

Базу запустить удалось с innodb_force_recovery = 5

Жалуется на конкретную таблицу

SQL-error N:1036: Table 'tbl_oper' is read only Error Text: UPDATE tbl_oper SET LASTACT = '2018-02-13 14:41:25' WHERE CODE = 1

SQL-error N:1036: Table 'tbl_oper' is read only Error Text: UPDATE tbl_oper SET LASTACT = '2018-02-13 14:41:25' WHERE CODE = 1

innodb_force_recovery > 0 вся база только для чтения доступна

2018-02-13 14:45:00 140623709436096 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11 2018-02-13 14:45:00 140623709436096 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files. 2018-02-13 14:45:01 140623709436096 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11

то есть, бэкапов, я так понимаю, нет? ?

за 16.01

bpvtytybq gjxnb yt ,skj

изменений почти не было

но с конкретно этой таблицей проблемы уже были

а что мне мешает дополнить перечень ENUM ?

вот тут перечислены все причины, почему ENUM говно. а также редкие случаи, когда оно всё-таки подходит: http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

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

за 16.01

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

Может тут есть люди кто получил сертификат 1Z0-883

Hello Denis How are you? I need to ask you something please. Did you have made the Exam for the 1Z0-883 certification? I am sorry but i dont speak russian. Thank you!

Всем привет. Подскажите плз, в каких случая нужно использовать unique index, а в каких constraints? Везде читаю о том, что функциональной разницы нет

?Как нет? совсем разные вещи так-то

Одно гарантирует, что такой записи у тебя больше не будет, второе - что такая запись есть в другой таблице

Народ, как можно провести optimize table если не хватает диска ? )

Есть какие-нибудь костыли? =)

Освободиться от остального? Вынести бин/релей логи на другой раздел... Может так ххватаит?))))

Да уже все что мог почистил и перенес

Тогда наверное только временный экспорт куда-то чего-то большого из базы...

Понял спасибо. А вообще насколько эффитивен optimize на innodb? Табличка примерно 30 ГБ, данные удаляется пачками. После очередного удаления сразу можно смотреть размер idb файла (уменьшился) ли? Или мускул сразу так просто диск не отдаст?

не отдаст

Частично это место будет заполнено новыми записями

Частично - так и останется висеть мёртвым грузом

Ну вот optimize по идее должен это "отформатировать" ? Или нет?

да