2017-01-25 13 views
1

Я не подключены к базе данных MySQL с помощью пакета RMySQL, используя это заявление:Как проверить, сохраняется ли соединение с MySql через RMySql?

con<-dbConnect(drv=RMySQL::MySQL(max.con=1,fetch.default.rec=500),host="host",dbname="dbname",password="psswd",user="user")) 

До сих пор никаких проблем. Когда я проверяю:

>class(con) 
[1] "MySQLConnection" 
attr(,"package") 
[1] "RMySQL" 

Через час я использовал следующее заявление:

dbGetQuery(conn=con,"show tables") 

и я получил ошибку:

Error in .local(dbObj, ...) : 
internal error in RS_DBI_getConnection: corrupt connection handle 

Однако, если я проверить это утверждение:

dbListConnections(drv=RMySQL::MySQL()) 

Он дает:

[[1]] 
<MySQLConnection:0,21> 

Когда я пытаюсь:

dbDisconnect(conn=con) 

я получаю ту же ошибку:

Error in .local(dbObj, ...) : 
internal error in RS_DBI_getConnection: corrupt connection handle 

Затем я удалил объект соединения:

rm(con) 

Когда я попытался подключиться снова используя dbConnect(), я получил эту ошибку:

con<-dbConnect(drv=RMySQL::MySQL(max.con=1,fetch.default.rec=500),host="host",dbname="dbname",password="psswd",user="user")) 
Error in .local(drv, ...): Cannot allocate a new connection: 1 connections already opened 

Я знаю, что вызов dbListConnections() возвращает пустой список, когда нет соединения с базой данных. Но в этом случае не возвращается пустой список.

ли повредиться соединение обрабатывать различные состояния соединения, чем отключенного состояния?

OR

Соединение имеет временные ограничения?

Каков наилучший подход, чтобы проверить, работает ли соединение с БД?

+2

Сохранение связи для этого долгое время является очень ОЧЕНЬ серьезной ошибкой. Вы должны закрыть соединение, как только закончите использовать его.Причина в том, что любые транзакции, блокировки, которые были приобретены при открытии соединения, сохраняются до закрытия, что приводит к серьезной деградации производительности. Просто закройте соединение и откройте его * ТОЛЬКО * при необходимости –

+1

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

+0

@PanagiotisKanavos Okay. Спасибо, что указали на ошибку. Поэтому я должен предположить, что это ошибка реализации с моей стороны, а не проблема с пакетом? – TUSHAr

ответ

1

Возможно, вам необходимо закрыть соединение с dbDisconnect(con) вместо rm(con), чтобы освободить ручку внутреннего соединения и разрешить новое соединение. Последний удаляет только «указатель» на объект соединения (так что вы больше не можете получить доступ к этому объекту через con), но он все еще существует физически до garbage collection.

Вы можете проверить, действительно ли соединение действительное через dbIsValid(con), или используйте простой dbGetQuery(con, "SELECT 1"). Мне было бы интересно узнать, обнаружил ли первый из них разрыв в вашей системе, есть discussion on GitHub вокруг этой темы.

+0

Я попробовал dbDisconnect (con), как указано в вопросе. Но он выдает ошибку поврежденного соединения. Я собираюсь проверить команду dbIsValid (con) завтра. – TUSHAr

+0

Я установил соединение, запросил DB и отключил его, используя dbDisconnect (con). После этого, если я выполню, dbIsValid (con): я получаю ошибку коррумпированного соединения. Но используя тот же (con), я могу снова подключиться к db. Я не проверял это для связи, которая поддерживалась в течение длительного времени, поскольку я изменил свой код в соответствии с предложениями от @Panagiotis Kanavos. – TUSHAr

+1

Вы заглянули в пул? Вот [Github repo] (https://github.com/rstudio/pool), и вот [статья вступления] (http://shiny.rstudio.com/articles/pool-basics.html). Он делает все это для вас ... Это в основном позволяет вам не беспокоиться о том, что намекнул @Panagiotis Kanavos, когда писал: «Сохранение открытой связи надолго - очень, ОЧЕНЬ серьезная ошибка». Он будет следить за тем, чтобы вы не делали этого, предоставляя вам то же семантику. –

 Смежные вопросы

  • Нет связанных вопросов^_^