Bug 38668 - Не создаются таблицы в БД mariadb
Summary: Не создаются таблицы в БД mariadb
Status: NEW
Alias: None
Product: Branch p9
Classification: Distributions
Component: mariadb (show other bugs)
Version: не указана
Hardware: x86_64 Linux
: P5 normal
Assignee: Alexey Shabalin
QA Contact: qa-p9@altlinux.org
URL: https://jira.mariadb.org/browse/MDEV-...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-03 16:25 MSK by Iwan
Modified: 2020-09-07 04:55 MSK (History)
5 users (show)

See Also:


Attachments
логфайл с трейсом (566.17 KB, text/plain)
2020-07-03 16:25 MSK, Iwan
no flags Details
Полный лог миграции (6.97 KB, text/x-log)
2020-08-10 14:37 MSK, Alexander
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Iwan 2020-07-03 16:25:41 MSK
Created attachment 8853 [details]
логфайл с трейсом

После обновления сервера БД mariadb от 02.07.2020 перестала работать миграция для БД.

Доступ к базам есть, сами базы создаются от учетных записей пользователей.
Но при попытке миграции валятся ошибки:
----------------------------
oslo_db.exception.DBError: (pymysql.err.InternalError) (1005, 'Can\'t create table `magnum`.`alembic_version` (errno: 165 "Table is read only")')
[SQL: 
CREATE TABLE alembic_version (
	version_num VARCHAR(32) NOT NULL, 
	CONSTRAINT alembic_version_pkc PRIMARY KEY (version_num)
)

]
(Background on this error at: http://sqlalche.me/e/2j85)
----------------------------------
Полный лог-файл во вложении.

# rpm -qa | grep mariadb
mariadb-server-control-10.4.13-alt1.noarch
mariadb-common-10.4.13-alt1.noarch
mariadb-client-10.4.13-alt1.x86_64
mariadb-server-10.4.13-alt1.x86_64
libmariadb3-10.4.13-alt1.x86_64

[altlinux@test ~]$ cat /etc/redhat-release
ALT p9 starter kit (Hypericum)


Дополнительные опции, которые мы используем:
[mysqld]
default-storage-engine = innodb
innodb_file_per_table
max_connections = 4096
collation-server = utf8_general_ci
character-set-server = utf8
connect_timeout = 43200
max_allowed_packet = 1024M
net_buffer_length = 512M
innodb_force_recovery = 4

Но и при опциях по умолчанию проблема остается.
Comment 1 Константин 2020-07-06 15:27:46 MSK
Можете подробнее описать свой стенд?
Как настроена миграция?
Кластер Galera работает без проблем.
Репликация Master - Slave так же проходит успешно.
Comment 2 Iwan 2020-07-06 17:44:38 MSK
(Ответ для Константин на комментарий #1)
> Можете подробнее описать свой стенд?
> Как настроена миграция?
> Кластер Galera работает без проблем.
> Репликация Master - Slave так же проходит успешно.

rpm -qa | grep maria
mariadb-common-10.4.13-alt1.noarch
mariadb-client-10.4.13-alt1.x86_64
libmariadb3-10.4.13-alt1.x86_64

Репликация Master - Slave - нет. Нет вообще никакой репликации, сервер развернут в единственном экземпляре.

Создается БД:
CREATE DATABASE nova;

Задаются права пользователю на БД:
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY '123456';

На выполнении запроса:
# su -s /bin/sh -c "nova-manage db sync" nova
операция завершается трейсом такого вот типа:
----------------------------
oslo_db.exception.DBError: (pymysql.err.InternalError) (1005, 'Can\'t create table `aggregate_hosts`.`alembic_version` (errno: 165 "Table is read only")')
[SQL: 
CREATE TABLE alembic_version (
	version_num VARCHAR(32) NOT NULL, 
	CONSTRAINT alembic_version_pkc PRIMARY KEY (version_num)
)

]
(Background on this error at: http://sqlalche.me/e/2j85)
----------------------------------


На предыдущей версии mariadb подобного поведения не наблюдалось.
Comment 3 Alexey Shabalin 2020-07-10 20:56:35 MSK
1) предыдущая версия mariadb, это какая?
2) запускали ли mysql_upgrade(или mariadb-upgrade)?
3) какие версии используются python, pymysql, alembic, SQLAlchemy, nova.
Comment 4 Iwan 2020-07-10 22:04:11 MSK
(Ответ для Alexey Shabalin на комментарий #3)
> 1) предыдущая версия mariadb, это какая?
> 2) запускали ли mysql_upgrade(или mariadb-upgrade)?
> 3) какие версии используются python, pymysql, alembic, SQLAlchemy, nova.

1. Предыдущая версия (на которой все работало): 10.4.12, Текущая версия (на которой возникли проблемы): 10.4.13-alt1

2. Не запускали. Производилась чистая установка на только что развернутую ОС.
Выполняемые действия:
--------------------------------------
1.Установка пакета БД, настройка параметров (указаны ранее)
2.Установка пароля суперадмина
3.Создание базы модуля
4.Создание пользователя и его пароля для базы модуля
5.Миграция средствами openstack
--------------------------------------

3. Python 3.7.4, Nova 20.3, python3-module-SQLAlchemy-1.3.8-alt1, python3-module-alembic-1.3.1-alt1, python3-module-pymysql-0.9.3-alt1


На всякий случай уточняю, что в данный момент вынуждены использовать БД на внешнем сервере с Debian.
Comment 5 Alexey Shabalin 2020-07-15 17:58:31 MSK
(Ответ для Iwan на комментарий #4)
> На всякий случай уточняю, что в данный момент вынуждены использовать БД на
> внешнем сервере с Debian.

Можно из архива поставить mariadb-10.4.12
(https://www.altlinux.org/%D0%90%D1%80%D1%85%D0%B8%D0%B2_%D0%A1%D0%B8%D0%B7%D0%B8%D1%84%D0%B0#p9)
и поставить этот пакет на Hold 
(https://www.altlinux.org/Hold),
пока проблема не будет решена в апстриме
https://jira.mariadb.org/browse/MDEV-23181)
Comment 6 Alexey Shabalin 2020-08-08 22:17:11 MSK
Апстрим просит конкретную sql команду, которая не работает и приводит к ошибке.
Comment 7 Alexander 2020-08-10 14:37:20 MSK
Created attachment 8901 [details]
Полный лог миграции

команда создания таблицы 
CREATE TABLE migrate_version (\trepository_id VARCHAR(250) NOT NULL, \trepository_path TEXT, \tversion INTEGER, \tPRIMARY KEY (repository_id));