NI
лучше менять tx_isolation на READ COMMITTED, будет более явно что хочется сделать. Ну и заодно trx_commit=0/2 sync_binlog=0/>100 по желанию, если конечно все узлы на одном физическом сервере не крутятся
Size: a a a
2020 April 15
ЕО
лучше менять tx_isolation на READ COMMITTED, будет более явно что хочется сделать. Ну и заодно trx_commit=0/2 sync_binlog=0/>100 по желанию, если конечно все узлы на одном физическом сервере не крутятся
3 дедика в хецнере на одном маршрутизаторе, латенси как в локалке, стабильная 115 МиБ/с сетка
ЕО
лучше менять tx_isolation на READ COMMITTED, будет более явно что хочется сделать. Ну и заодно trx_commit=0/2 sync_binlog=0/>100 по желанию, если конечно все узлы на одном физическом сервере не крутятся
Спасибо. А как посмотреть какой сейчас стоит sync_binlog ?
и в случае с галерой бинлог по умолчанию отключен:
Как и в случае репликации MariaDB , наборы записи, полученные узлом с репликацией Galera Cluster на основе сертификации, по умолчанию не записываются в двоичный журнал . Если вы хотите, чтобы узел записывал свои реплицированные наборы записи в двоичный журнал
и в случае с галерой бинлог по умолчанию отключен:
Как и в случае репликации MariaDB , наборы записи, полученные узлом с репликацией Galera Cluster на основе сертификации, по умолчанию не записываются в двоичный журнал . Если вы хотите, чтобы узел записывал свои реплицированные наборы записи в двоичный журнал
ЕО
innodb_flush_log_at_trx_commit = 0 уже был настроен раньше
AG
добрый день коллеги...
помогите продебажить проблему
Есть две абсолютно идентичные виртуалки на гугле облаке с Percona 8.0.19-10, конфиг абсолютно тот-же разница только в базах данных. На каждой машине порядка 10000 баз.
Одна из них крашится примерно с 3недельной периодичностью с таким вот логом
помогите продебажить проблему
Есть две абсолютно идентичные виртуалки на гугле облаке с Percona 8.0.19-10, конфиг абсолютно тот-же разница только в базах данных. На каждой машине порядка 10000 баз.
Одна из них крашится примерно с 3недельной периодичностью с таким вот логом
13:44:25 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7fed09633c10
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7fef46212c30 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x200b90d]
/usr/sbin/mysqld(handle_fatal_signal+0x333) [0x11cf0f3]
/lib64/libpthread.so.0(+0xf5f0) [0x7ffa1773f5f0]
/usr/sbin/mysqld(dict_foreign_qualify_index(dict_table_t const*, char const**, char const**, unsigned long, dict_index_t const*, dict_index_t const*, bool, unsigned long)+0xa1) [0x23ab4f1]
/usr/sbin/mysqld(dict_foreign_find_index(dict_table_t const*, char const**, char const**, unsigned long, dict_index_t const*, bool, unsigned long)+0x8c) [0x23ab68c]
/usr/sbin/mysqld() [0x20ff35a]
/usr/sbin/mysqld(bool ha_innobase::commit_inplace_alter_table_impl<dd::Table>(TABLE*, Alter_inplace_info*, bool, dd::Table const*, dd::Table*)+0x110d) [0x211603d]
/usr/sbin/mysqld(ha_innobase::commit_inplace_alter_table(TABLE*, Alter_inplace_info*, bool, dd::Table const*, dd::Table*)+0xae) [0x21186ae]
/usr/sbin/mysqld() [0x1117ec4]
/usr/sbin/mysqld(mysql_alter_table(THD*, char const*, char const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*)+0x61c5) [0x112c2f5]
/usr/sbin/mysqld(Sql_cmd_alter_table::execute(THD*)+0x483) [0xfed8a3]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x3c90) [0x108da00]
/usr/sbin/mysqld(Prepared_statement::execute(String*, bool)+0x949) [0x10bc359]
/usr/sbin/mysqld(Prepared_statement::execute_loop(String*, bool)+0xb4) [0x10bebe4]
/usr/sbin/mysqld(mysqld_stmt_execute(THD*, Prepared_statement*, bool, unsigned long, PS_PARAM*)+0x191) [0x10c01f1]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x1895) [0x1091875]
/usr/sbin/mysqld(do_command(THD*)+0x204) [0x1092ce4]
/usr/sbin/mysqld() [0x11c0050]
/usr/sbin/mysqld() [0x24e57dc]
/lib64/libpthread.so.0(+0x7e65) [0x7ffa17737e65]
/lib64/libc.so.6(clone+0x6d) [0x7ffa158be88d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fed0984d498): alter table user_group_to_coupons add constraint user_group_to_coupons_user_group_id_foreign foreign key (user_group_id) references user_groups (id) on delete CASCADE on update CASCADE
Connection ID (thread ID): 4965497
Status: NOT_KILLED
Please help us make Percona Server better by reporting any
bugs at https://bugs.percona.com/
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
2020-04-15T13:44:36.673526Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19-10) starting as process 4131
100 200
2020-04-15T14:04:41.324762Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
2020-04-15T14:04:41.348223Z 0 [System] [MY-010232] [Server] XA crash recovery finished.
2020-04-15T14:04:42.225483Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-04-15T14:04:42.731240Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.19-10' socket: '/var/lib/mysql/mysql.sock' port: 3306 Percona Server (GPL), Release 10, Revision f446c04.AG
второй сервер работает четко как швейцарские часы
2020 April 16
AG
в продолжение предыдущего вопроса, как я могу убедиться, что у меня нет поврежденных индексов и баз данных?
ПД
подскажите, почему когда делаю
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
OD
подскажите, почему когда делаю
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
Может ошибаюсь, но можете попробовать
$stmp = $stmp->execute();
$stmp = $stmp->execute();
ПД
а что должно поменяться? объясните пожалуйста
ПД
Может ошибаюсь, но можете попробовать
$stmp = $stmp->execute();
$stmp = $stmp->execute();
в том плане, что вся конструкция работает если один select или один insert или 2 inserta, но вот последовательно insert, затем select - не поиходит ответ
OD
в том плане, что вся конструкция работает если один select или один insert или 2 inserta, но вот последовательно insert, затем select - не поиходит ответ
Аааа даже так
OD
Значит мой вариант не верный
V
подскажите, почему когда делаю
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
Подумайте нужны ли вам Prepared Statements в MySQL. Если планируете что нагрузка будет высокой, они вам могут серьезно помешать.
ПД
Подумайте нужны ли вам Prepared Statements в MySQL. Если планируете что нагрузка будет высокой, они вам могут серьезно помешать.
ок, но позже)
еще добраться до этапа с нагрузками надо
еще добраться до этапа с нагрузками надо
А
подскажите, почему когда делаю
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
$sql = '
INSERT INTO tbl (a,b)
VALUES (1,2)
SELECT max( a ) ,b
FROM tbl
WHERE b =5;';
$stmt = $db->prepare($sql);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
запрос выполняется (в логе видно), но ответ не приходит, а если без insert отправляю, то ответ приходит.
если 2 insert отсылаю, то оба выполняются
а что этой конструкцией вы хотите сделать?