Depois de muitas tentativas, consegui reiniciar um banco de dados muito corrompido adicionando innodb_force_recovery = 6 ao meu.ini
No entanto, agora, não consigo iniciar o servidor de forma alguma, a menos que essa linha esteja permanentemente no arquivo ini. Isso não parece certo.
Há algo que eu deva fazer depois de recuperar um banco de dados dessa maneira, além de fazer backup e restaurar em um novo?
Eu executo o MySQL em um contêiner docker:
sudo docker run --rm --name mysql5 --net legacy_net --net-alias mysql5 --ip 172.20.0.2 -e MYSQL_ROOT_PASSWORD=$MROOTPASS -d mysql:5.7
mysql -u root -h 172.20.0.2 -p$MROOTPASS
e criou um banco de dados experimental com o seguinte comando:
CREATE DATABASE testdb;
e comprometeu o contêiner:
sudo docker commit mysql5 mysql:5.7-test
Quando iniciei o contêiner comprometido:
sudo docker stop mysql5;
sudo docker run --rm --name mysql5 --net legacy_net --net-alias mysql5 --ip 172.20.0.2 -e MYSQL_ROOT_PASSWORD=$MROOTPASS -d mysql:5.7-test
meu banco de dados de teste desapareceu.
É um comportamento normal ou fiz algo errado?
Meu entendimento era que o Docker armazena seus dados em algum lugar em seu armazenamento interno que é copiado para a nova imagem quando eu faço isso docker commit. O que eu entendi errado?
EDITAR1
sudo docker inspect mysql5 | grep -i volume
"VolumeDriver": "",
"VolumesFrom": null,
"Type": "volume",
"Source": "/var/lib/docker/volumes/1f04f07e91a16e6e9aeb393af2954dd7e32e2a2b93615fb4b6924de3568951af/_data",
"Volumes": {
sudo docker inspect mysql:5.7
"Volumes": {
"/var/lib/mysql": {}
},
EDITAR2
O Docker cria o volume com seu mysqlusuário que tem id=999:
sudo docker run --rm --name mysql5 -v /home/dmitriano/work/mysql:/var/lib/mysql --net legacy_net --net-alias mysql5 --ip 172.20.0.2 -e MYSQL_ROOT_PASSWORD=$MROOTPASS -d mysql:5.7
ll
drwxr-xr-x 5 999 root 4096 Jan 20 19:31 mysql/
sudo docker exec -it mysql5 bash -c "id 999"
uid=999(mysql) gid=999(mysql) groups=999(mysql)
O que devo fazer com este 999 na máquina host?
Migrei 3 dos meus 11 bancos de dados do MySQL 5.7.44 no Ubuntu 16.04 para o MySQL 8.0.40 no Ubuntu 24.04.
O espaço usado na minha máquina antiga:
root@localhost:/var/lib/mysql# du -ha --max-depth=1
19M ./bot
4.0K ./private_key.pem
1.1M ./performance_schema
48K ./game
79M ./master
4.0K ./public_key.pem
4.0K ./client-key.pem
4.0K ./auto.cnf
5.0G ./beauty
0 ./debian-5.7.flag
201M ./devnote
11M ./mysql
4.0K ./ca.pem
8.0K ./test
12M ./mike1
12M ./ibtmp1
176K ./phpmyadmin
4.0K ./server-cert.pem
680K ./sys
48M ./ib_logfile0
4.0K ./ca-key.pem
127M ./mike
4.0K ./mysql_upgrade_info
4.0K ./ib_buffer_pool
48M ./ib_logfile1
4.0K ./server-key.pem
186M ./slogpost
76M ./ibdata1
4.0K ./client-cert.pem
41M ./shar
5.9G .
O espaço usado na minha nova máquina (os novos bancos de dados são beauty, shar, slogpost):
root@localhost:/var/lib/mysql# du -ha --max-depth=1
101M ./#innodb_redo
101M ./binlog.000161
101M ./binlog.000069
101M ./binlog.000008
101M ./binlog.000095
101M ./binlog.000082
101M ./binlog.000047
4.0K ./localhost.pid
4.0K ./public_key.pem
101M ./binlog.000075
36K ./mysql
101M ./binlog.000177
101M ./binlog.000101
101M ./binlog.000122
4.0K ./server-key.pem
101M ./binlog.000107
101M ./binlog.000158
101M ./binlog.000079
101M ./binlog.000057
101M ./binlog.000028
101M ./binlog.000173
101M ./binlog.000020
4.0K ./binlog.index
101M ./binlog.000112
101M ./binlog.000121
101M ./binlog.000139
101M ./binlog.000142
101M ./binlog.000152
101M ./binlog.000060
101M ./binlog.000136
101M ./binlog.000010
101M ./binlog.000045
101M ./binlog.000077
101M ./binlog.000125
101M ./binlog.000168
101M ./binlog.000169
101M ./binlog.000119
101M ./binlog.000007
101M ./binlog.000176
101M ./binlog.000127
101M ./binlog.000066
4.0K ./client-key.pem
101M ./binlog.000123
101M ./binlog.000099
101M ./binlog.000143
101M ./binlog.000118
4.0K ./private_key.pem
101M ./binlog.000070
101M ./binlog.000145
101M ./binlog.000030
4.0K ./binlog.000002
19M ./shar
4.0K ./auto.cnf
101M ./binlog.000116
101M ./binlog.000160
101M ./binlog.000156
101M ./binlog.000148
101M ./binlog.000097
101M ./binlog.000043
101M ./binlog.000140
101M ./binlog.000042
101M ./binlog.000063
101M ./binlog.000015
101M ./binlog.000050
0 ./debian-5.7.flag
101M ./binlog.000003
101M ./binlog.000180
8.2M ./#ib_16384_1.dblwr
4.0K ./binlog.000036
101M ./binlog.000026
12M ./ibtmp1
101M ./binlog.000034
1.7M ./performance_schema
16M ./undo_002
101M ./binlog.000023
101M ./binlog.000071
101M ./binlog.000033
32K ./binlog.000038
101M ./binlog.000011
76K ./binlog.000039
101M ./binlog.000110
101M ./binlog.000017
101M ./binlog.000012
101M ./binlog.000032
101M ./binlog.000165
101M ./binlog.000086
101M ./binlog.000157
183M ./slogpost
2.3G ./binlog.000133
101M ./binlog.000056
101M ./binlog.000019
101M ./binlog.000022
2.3G ./binlog.000183
101M ./binlog.000073
101M ./binlog.000138
101M ./binlog.000009
101M ./binlog.000067
101M ./binlog.000181
101M ./binlog.000013
101M ./binlog.000162
101M ./binlog.000088
101M ./binlog.000120
101M ./binlog.000054
101M ./binlog.000064
8.6M ./binlog.000035
101M ./binlog.000085
101M ./binlog.000144
101M ./binlog.000091
101M ./binlog.000061
101M ./binlog.000141
4.0K ./binlog.000135
101M ./binlog.000109
101M ./binlog.000103
101M ./binlog.000132
101M ./binlog.000094
101M ./binlog.000151
101M ./binlog.000076
101M ./binlog.000149
101M ./binlog.000104
101M ./binlog.000163
101M ./binlog.000027
101M ./binlog.000114
116K ./sys
101M ./binlog.000182
8.0K ./ib_buffer_pool
101M ./binlog.000115
101M ./binlog.000164
101M ./binlog.000084
2.4G ./beauty
101M ./binlog.000016
101M ./binlog.000153
101M ./binlog.000172
101M ./binlog.000041
101M ./binlog.000174
101M ./binlog.000100
8.0K ./binlog.000185
101M ./binlog.000113
101M ./binlog.000046
101M ./binlog.000178
101M ./binlog.000124
101M ./binlog.000074
101M ./binlog.000105
101M ./binlog.000179
28M ./mysql.ibd
101M ./binlog.000171
101M ./binlog.000155
101M ./binlog.000062
101M ./binlog.000021
101M ./binlog.000044
101M ./binlog.000049
101M ./binlog.000059
101M ./binlog.000147
60K ./binlog.000134
101M ./binlog.000055
4.0K ./binlog.000040
101M ./binlog.000126
101M ./binlog.000170
101M ./binlog.000089
101M ./binlog.000006
101M ./binlog.000080
101M ./binlog.000081
101M ./binlog.000068
172K ./binlog.000037
12M ./ibdata1
101M ./binlog.000146
101M ./binlog.000031
101M ./binlog.000129
101M ./binlog.000150
4.0K ./binlog.000001
804K ./#innodb_temp
101M ./binlog.000065
75M ./binlog.000004
4.0K ./ca-key.pem
101M ./binlog.000025
101M ./binlog.000108
4.0K ./server-cert.pem
101M ./binlog.000090
101M ./binlog.000051
101M ./binlog.000048
101M ./binlog.000052
101M ./binlog.000024
101M ./binlog.000053
101M ./binlog.000130
101M ./binlog.000014
8.0K ./binlog.000184
101M ./binlog.000117
101M ./binlog.000096
101M ./binlog.000005
101M ./binlog.000175
101M ./binlog.000131
101M ./binlog.000078
101M ./binlog.000167
101M ./binlog.000058
101M ./binlog.000083
101M ./binlog.000087
101M ./binlog.000154
101M ./binlog.000166
101M ./binlog.000102
4.0K ./client-cert.pem
101M ./binlog.000128
4.0K ./ca.pem
101M ./binlog.000137
101M ./binlog.000098
16M ./undo_001
101M ./binlog.000029
101M ./binlog.000018
101M ./binlog.000092
101M ./binlog.000106
101M ./binlog.000072
101M ./binlog.000111
2.3G ./binlog.000159
192K ./#ib_16384_0.dblwr
101M ./binlog.000093
27G .
du -csh binlog* | tail -n 1
24G total
(O banco de dados beautyna máquina antiga ocupa 5,0 G porque contém alguns dados extras)
11 bancos de dados na nova máquina ocupam 5,9 G, mas 3 bancos de dados na máquina antiga ocupam 27 G.
Por que tanto?
Para fazer backup de um banco de dados, eu simplesmente faço isso :
mysqldump -u $MUSER -h $MHOST -p$MPASS $MDB --no-tablespaces | sed -e 's/DEFINER=[^*]*\*/\*/' > $DBDUMP
para restaurar eu faço isso :
tar -Oxzf $ARCHIVE_FILE $DBDUMP | mysql -u $MUSER -h $MHOST -p$MPASS $MDB
Estou tentando configurar a replicação entre dois servidores mysql 5.7. Consigo conectar à fonte a partir da réplica, mas quando tento iniciar a replicação, a réplica falha ao conectar à fonte. O que pode causar isso
Isso abre com sucesso um cliente mysql conectado à fonte:
# On replica
$ mysql -u [my_user] -p -h [source_host] \
--ssl-mode=REQUIRED \
--ssl-ca=/etc/[source_host].cabundle
Status da fonte:
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.002513 | 45687316 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
Na réplica:
mysql> CHANGE MASTER TO
-> MASTER_HOST='[source_host]',
-> MASTER_USER='[my_user]',
-> MASTER_PASSWORD='[my_password]',
-> MASTER_LOG_FILE='mysql-bin.002495',
-> MASTER_LOG_POS=154,
-> MASTER_SSL=1,
-> MASTER_SSL_VERIFY_SERVER_CERT=0,
-> MASTER_SSL_CA='/etc/ssl/[source_host].cabundle'
-> ;
Query OK, 0 rows affected, 2 warnings (0.03 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
Status da réplica:
mysql> show slave stauts \G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: [source_host]
Master_User: [my_user]
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.002495
Read_Master_Log_Pos: 154
Relay_Log_File: [hostname]-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.002495
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Relay_Log_Space: 154
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/ssl/[source_host].cabundle
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2026
Last_IO_Error: error connecting to master '[my_user]@[source_host]:3306' - retry-time: 60 retries:
4
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_UUID:
Master_Info_File: [mysql_dir]/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 250115 03:03:38
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
mysql error.log na réplica:
[Note] 'CHANGE MASTER TO FOR CHANNEL '' executed'. Previous state master_host='[source_host]', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='[source_host]', master_port= 3306, master_log_file='mysql-bin.002495', master_log_pos= 154, master_bind=''.
[Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[Warning] Slave SQL for channel '': If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
[Note] Slave SQL thread for channel '' initialized, starting replication in log 'mysql-bin.002495' at position 154, relay log './analysis-relay-bin.000001' position: 4
[ERROR] Slave I/O for channel '': error connecting to master '[my_user]@[source_host]:3306' - retry-time: 60 retries: 1, Error_code: 2026
mysql error.log na fonte:
[Note] Bad handshake
Estou me conectando ao MySQL com o usuário 'feedbackdev', mas as consultas são executadas com 'feedback', que é outro usuário no mesmo servidor.
root@board:~# mysql -u feedbackdev -p feedbackdev
Enter password:
mysql> select user();
+-----------------------+
| user() |
+-----------------------+
| feedbackdev@localhost |
+-----------------------+
mysql> select rating, COUNT(*) AS rating_count from order_feedback_view where feedback_created_at >= '2024-10-26 09:01:29' group by rating;
ERROR 1143 (42000): SELECT command denied to user 'feedback'@'localhost' for column 'source_id' in table 'orders'
Aqui estão as SUBVENÇÕES para os usuários
mysql> show grants for 'feedbackdev'@'localhost';
+----------------------------------------------------------------------+
| Grants for feedbackdev@localhost |
+----------------------------------------------------------------------+
| GRANT PROCESS, SUPER ON *.* TO `feedbackdev`@`localhost` |
| GRANT SET_USER_ID ON *.* TO `feedbackdev`@`localhost` |
| GRANT ALL PRIVILEGES ON `feedbackdev`.* TO `feedbackdev`@`localhost` |
+----------------------------------------------------------------------+
3 rows in set (0.00 sec)
mysql> show grants for 'feedback'@'localhost';
+---------------------------------------------------------------------------+
| Grants for feedback@localhost |
+---------------------------------------------------------------------------+
| GRANT PROCESS, SUPER, REPLICATION CLIENT ON *.* TO `feedback`@`localhost` |
| GRANT FLUSH_TABLES ON *.* TO `feedback`@`localhost` |
| GRANT ALL PRIVILEGES ON `feedback`.* TO `feedback`@`localhost` |
+---------------------------------------------------------------------------+
3 rows in set (0.00 sec)
MySQL versão 8.0.40
Ao executar o SHOW MASTER STATUS;comando, recebo um erro de sintaxe. Isso é super estranho. Verifiquei os privilégios, eles estão ok. O server-ide bin-logestão ambos definidos e funcionando. Não há replicação em andamento. E se o problema fosse com privilégios ou algumas configurações não definidas corretamente, eu não receberia um SyntaxError.
Aqui está o comando completo que executo:
mysql> SHOW MASTER STATUS;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'MASTER STATUS' at line 1
Eu tentei até mesmo executá-lo como root e ainda tenho um erro de sintaxe. Googlar e pesquisar os documentos não ajudou. A versão do MySQL é 8.4.0
Alguém pode me aconselhar qual poderia ser a causa dessa condição?
Eu tenho um cluster Rook Ceph no qual o banco de dados MySQL com replicação 3x está armazenado. Esse banco de dados também é usado por mim para desenvolvimento, ou seja, muitos dados são excluídos, alterados e assim por diante.
BinaryLogs também estão habilitados.
No total, o banco de dados ocupa 27 GB, dos quais 22 a 24 são BinaryLogs. Posso desabilitar BinaryLogs, mas 20 gigabytes não desempenham um papel importante, eles são apagados a cada 3 dias.
Vejo o mesmo tamanho (27 GB) se observar o tamanho do contêiner/host (df -h).
Mas Rook Ceph define esta imagem de bloco como 241 GB.
E não consigo entender por que esse tamanho de Block Image é tão grande se deveria ser 9 vezes menor?
Idéias, dicas? O que posso tentar ou em que direção olhar para entender qual é o motivo.
Segui passo a passo as instruções para implantar o operador MySQL no Kubernetes. Seguindo as instruções da página oficial. Uma vez implantado sem erros, o operador não estará no estado pronto. Eu tentei por meio de manifestos e Helm, mas obtive a mesma resposta.
https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-installation-kubectl.html
Depois de implantado, o operador não está pronto
$ kubectl get all -n mysql-operator
NAME READY STATUS RESTARTS AGE
pod/mysql-operator-84ffdf9dbc-m2n4c 0/1 Running 0 31s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/mysql-operator 0/1 1 0 31s
NAME DESIRED CURRENT READY AGE
replicaset.apps/mysql-operator-84ffdf9dbc 1 1 0 31s
Eu testei nas versões 1.24 e 1.27 do Kubernetes, obtendo os mesmos resultados.
Parece que o Operador tenta obter xxx-privsecrets, mas não consegue encontrá-lo
Alguém encontrou o mesmo problema e encontrou uma solução?
De nada!
Histórico
2024-05-29 06:46:52: Info: mysqlsh Ver 8.4.0 for Linux on x86_64 - for MySQL 8.4.0 (MySQL Community Server (GPL)) - build 15032060 - commit_id 4de2d1695fdc7089e81c99dcb042953620e444fb - product_id el8-x86-64bit rpm
2024-05-29 06:46:52: Info: Using credential store helper: /usr/bin/mysql-secret-store-login-path
2024-05-29 06:46:52: Info: Loading startup files...
2024-05-29 06:46:52: Info: Loading plugins...
[2024-05-29 06:46:55,639] root [INFO ] Auto-detected cluster domain: cluster.local
[2024-05-29 06:46:55,644] kopf.activities.star [INFO ] MySQL Operator/operator.py=2.1.3 timestamp=2024-04-29T07:16:37 kopf=1.35.4 uid=2
[2024-05-29 06:46:55,659] kopf.activities.star [INFO ] KUBERNETES_VERSION =1.24
[2024-05-29 06:46:55,659] kopf.activities.star [INFO ] OPERATOR_VERSION =2.1.3
[2024-05-29 06:46:55,659] kopf.activities.star [INFO ] OPERATOR_EDITION =community
[2024-05-29 06:46:55,659] kopf.activities.star [INFO ] OPERATOR_EDITIONS =['community', 'enterprise']
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] SHELL_VERSION =8.4.0
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] DEFAULT_VERSION_TAG=8.4.0
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] SIDECAR_VERSION_TAG=8.4.0-2.1.3
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] DEFAULT_IMAGE_REPOSITORY =container-registry.oracle.com/mysql
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] setuptools = 50.3.2
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] pip = 20.2.4
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] yarl = 1.9.4
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] websocket-client = 1.7.0
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] urllib3 = 2.2.0
[2024-05-29 06:46:55,660] kopf.activities.star [INFO ] typing-extensions = 4.9.0
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] six = 1.16.0
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] rsa = 4.9
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] requests = 2.31.0
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] requests-oauthlib = 1.3.1
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] PyYAML = 6.0.1
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] python-json-logger = 2.0.7
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] python-dateutil = 2.8.2
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] pyasn1 = 0.5.1
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] pyasn1-modules = 0.3.0
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] oauthlib = 3.2.2
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] multidict = 6.0.5
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] kubernetes = 23.6.0
[2024-05-29 06:46:55,661] kopf.activities.star [INFO ] kopf = 1.35.4
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] iso8601 = 2.1.0
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] idna = 3.6
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] google-auth = 2.27.0
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] frozenlist = 1.4.1
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] click = 8.1.7
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] charset-normalizer = 3.3.2
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] certifi = 2024.2.2
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] cachetools = 5.3.2
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] attrs = 23.2.0
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] async-timeout = 4.0.3
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] aiosignal = 1.3.1
[2024-05-29 06:46:55,662] kopf.activities.star [INFO ] aiohttp = 3.8.5
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] pytz = 2024.1
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] pyOpenSSL = 23.3.0
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] PyNaCl = 1.4.0
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] pycparser = 2.21
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] paramiko = 2.11.0
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] oci = 2.122.0
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] cryptography = 41.0.7
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] circuitbreaker = 1.4.0
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] cffi = 1.16.0
[2024-05-29 06:46:55,663] kopf.activities.star [INFO ] bcrypt = 3.2.2
[2024-05-29 06:46:55,664] kopf.activities.star [INFO ] antlr4-python3-runtime = 4.13.1
[2024-05-29 06:46:55,687] kopf.activities.star [ERROR ] Activity 'on_startup' failed with an exception. Will retry.
Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/kopf/_core/actions/execution.py", line 279, in execute_handler_once
result = await invoke_handler(
File "/usr/lib/mysqlsh/python-packages/kopf/_core/actions/execution.py", line 374, in invoke_handler
result = await invocation.invoke(
File "/usr/lib/mysqlsh/python-packages/kopf/_core/actions/invocation.py", line 139, in invoke
await asyncio.shield(future) # slightly expensive: creates tasks
File "/usr/lib64/python3.9/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/operator.py", line 44, in on_startup
operator_cluster.monitor_existing_clusters(clusters, logger)
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/innodbcluster/operator_cluster.py", line 45, in monitor_existing_clusters
g_group_monitor.monitor_cluster(
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/group_monitor.py", line 196, in monitor_cluster
account = RetryLoop(logger).call(cluster.get_admin_account)
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/shellutils.py", line 93, in call
return f(*args)
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/innodbcluster/cluster_api.py", line 1920, in get_admin_account
secrets = self.get_private_secrets()
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/innodbcluster/cluster_api.py", line 1822, in get_private_secrets
api_core.read_namespaced_secret(f"{self.name}-privsecrets", self.namespace))
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/api/core_v1_api.py", line 24803, in read_namespaced_secret
return self.read_namespaced_secret_with_http_info(name, namespace, **kwargs) # noqa: E501
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/api/core_v1_api.py", line 24890, in read_namespaced_secret_with_http_info
return self.api_client.call_api(
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/api_client.py", line 348, in call_api
return self.__call_api(resource_path, method,
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/api_client.py", line 180, in __call_api
response_data = self.request(
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/api_client.py", line 373, in request
return self.rest_client.GET(url,
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/rest.py", line 240, in GET
return self.request("GET", url,
File "/usr/lib/mysqlsh/python-packages/kubernetes/client/rest.py", line 234, in request
raise ApiException(http_resp=r)
kubernetes.client.exceptions.ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Audit-Id': '5c0f3f37-3732-4581-89e2-3bca443c832d', 'Cache-Control': 'no-cache, private', 'Content-Type': 'application/json', 'X-Kubernetes-Pf-Flowschema-Uid': 'b1d36932-a72f-4dcb-8aa3-d0a7c8ffd4d2', 'X-Kubernetes-Pf-Prioritylevel-Uid': 'b6ec6262-e0cf-415e-bf76-09433fc2daa3', 'Date': 'Wed, 29 May 2024 06:46:55 GMT', 'Content-Length': '224'})
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"secrets \"mysql-cluster-privsecrets\" not found","reason":"NotFound","details":{"name":"mysql-cluster-privsecrets","kind":"secrets"},"code":404}
Criei um produto SaaS. Estou usando PHP 8.3 com um banco de dados MySQL 8.0. Localmente isso é muito rápido! Nenhuma estrutura etc. é usada. A produção é executada no Azure. Tenho a seguinte configuração no Azure:
Base de dados
Azure Database for MySQL flexible server
- Burstable, B1s, 1 vCores, 1 GiB RAM, 20 GiB storage
- MySQL version 8
O custo ronda os 20 euros/mês.
Serviço de aplicativo
Azure Web App
Basic B1, 100 ACU/vCPU, 1 vCPU, 1.75 memory (GB), 10 GB storage
OS: Linux
O custo ronda os 10 euros/mês
o problema que estou enfrentando é que inicialmente quando um usuário aleatório acessa meu site e executa uma ação onde uma consulta ao banco de dados é necessária. O banco de dados é MUITO lento no início. Pode levar de 3 a 10 segundos! Após esse 'aquecimento', cada novo usuário que acessa o site não sofre atrasos e as consultas ao banco de dados são muito rápidas. Digamos que se passem de 30 a 60 minutos e não haja atividade no site e um novo usuário acesse o site, está muito lento novamente. Isso NÃO é algo que eu quero. O que devo fazer para remover esse 'aquecimento'?
Dir-se-ia que uma base de dados de ~20 euros/mês teria um desempenho melhor. Eu tive bancos de dados MySQL mais baratos e com melhor desempenho.
Notas:
Estou usando MySQL v8.0.35 com Django e python. Um site é usado para acessar o banco de dados com o site e o banco de dados hospedados na AWS. Quando o site tenta acessar o banco de dados de alguma forma, ocorre este erro:
OperationalError: (1045, "Access denied for user '<user>'@'*****' (using password: NO)")
O principal problema é que não entendo por que a senha não está sendo usada pelo site, apesar de estar incluída na configuração do banco de dados no meu arquivo django settings.py.
Para mim, isso é estranho porque, enquanto faço o ssh na instância do site, consigo executar este comando:
mysqladmin -h <endpoint> -u <user> -p version
é o mesmo acima e quando sou solicitado a inserir minha senha, ela é executada perfeitamente.
Também consigo fazer login no banco de dados executando este comando durante o ssh:
mysql -h <endpoint> -u <user> -p
Nesse ponto, insiro a mesma senha e posso entrar. Quando verifico as permissões do meu usuário, isso aparece
[
No arquivo de configurações que o Django está usando para obter qualquer informação do banco de dados, é isso que eu tenho:
DATABASES={
'default': {
'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'zombeewatch', # Or path to database file if using sqlite3.
'USER': '<user>', # Not used with sqlite3.
'PASSWORD': '<password>', # Not used with sqlite3.
'HOST': '<endpoint>', # Set to empty string for localhost. Not used with sqlite3.
'PORT': '3306', # Set to empty string for default. Not used with sqlite3.
}
}
Também posso usar python manage.pysem problemas, então o programa parece ser capaz de obter o banco de dados, o nome de usuário e a senha do meu arquivo de configurações perfeitamente.
Para ser honesto, não tenho ideia de para onde ir a partir daqui. Acho que o principal problema depende do motivo pelo qual o site está tentando fazer login no banco de dados sem uma senha, quando uma é fornecida. Eu sei que há algumas perguntas com o mesmo erro, mas o contexto por trás delas parece ser muito diferente. Se eu puder fornecer mais informações, por favor me avise!
**Observe que confirmei que a senha que estou usando no arquivo é a correta. No mínimo, é o mesmo que estou copiando e colando quando é solicitada uma senha para os comandos mysql e mysqladmin.