Mysql: ベストプラクティス

コードコメントに次のように書かれています。

DBハンドルは長寿命であり、多くのゴルーチン間で共有されることを目的としているため、DBを閉じることはめったにありません。

...だから私はノーだと思います。 最悪の場合、最大許容アイドル接続の構成に基づいて、タイムアウトするか、自動的に閉じられますか？

SetConnMaxLifetimeを参照してください

また、http： //go-database-sql.org/accessing.html （番号付きリストの後の部分）も参照してください。

@benguild SetConnMaxLifetime 、 SetMaxIdleConns 、 SetMaxOpenConnsをどのように構成しましたか

さまざまな負荷条件に合わせて設定するためのベストプラクティスの原則をどこで得ることができるかについてのアイデアはありますか？

1年以上の間、リクエストの開始時にOpen()し、リクエストのライフサイクルの終了時にClose()を使用して、このドライバーを使用してきました。 それは完璧に機能しました。

このアドバイスを聞いて、私は1つの接続を開き、参照をグローバル変数に残して、それを使い続けます。 私はそれを決して閉じません。

SetConnMaxLifetime 、 SetMaxIdleConns 、 SetMaxOpenConns設定していません。 それらはデフォルトのままです。

この単純なテクニックは私にはうまくいきません。 CloudSQLへのアクティブな接続の数は、Google AppEngineの接続制限に達するまで増え続けます。 その後、データベースに接続できなくなります。

接続が閉じられていません。

CloudSQLのGoサンプルは、開始時に1回だけOpen()を呼び出します： https ：//github.com/GoogleCloudPlatform/golang-samples/blob/master/getting-started/bookshelf/db_mysql.go

この問題はCloudSQLに固有のものであり、ドライバー自体に関連しているのではないでしょうか。

たぶん@broadyはいくつかの洞察を持っていますか？

さて、私は今閉じていません。 それが問題が始まった時です。

そのサンプルコードは、接続が長続きすることを理解して作成しました。 私は実際に本番アプリでGoのSQLを使用したことがありません。

タイムアウト（したがって、定期的なキープアライブpingが必要）が原因で切断されていますか、それともソケットが壊れているために切断されていますか？

誰がこれを処理する必要がありますか？ ドライバーまたはユーザー？

実は、私が言ったことはあまり意味がありません。 sqlパッケージは、プール内の不正な接続を処理する必要があります。 この問題をこのドライバーに限定しましたか、それともdatabase / sqlのバグですか？

@pjebs接続を開いた直後にそれらを呼び出しています。
正直なところ、これらのパラメーター（ SetMaxOpenConns ）を設定しないと、必要な数の接続が確立されるようです。 SetConnMaxLifetimeを5分または10分に設定して、接続が閉じられるかどうかを確認しましたか？

接続が開いたらすぐにこれらを呼び出してみてください。

db.DB().SetConnMaxLifetime(time.Minute*5);
db.DB().SetMaxIdleConns(0);
db.DB().SetMaxOpenConns(5);

これまでに5接続を超えているかどうか、および接続のいずれかが5分を超えてアイドル状態になっていないかどうかを確認します。 お知らせ下さい。 使用可能なプールにアイドル状態の接続がない場合はハングすると思いますが、コードを読んでいないため、その場合は失敗する可能性があります。

アプリケーションコードに問題があるのではないかと思います。 ハンドラーが結果セットを閉じていない場合、既存の接続がまだ使用されているため、ドライバーはますます多くの接続を開く必要があります。 リクエストごとに接続が開かれたり閉じられたりすると、進行中のクエリによって開いたままになっている接続が終了するため、接続が積み重なることはありません。

これは、単一のグローバル持続的接続への切り替えで問題が発生した理由を説明しています。

また、 @ pjebsは、コードのどこかに偶然に追加のデータベースプールを作成していないことを（明らかに）確認してください。 どこかに新しいプールが割り当てられている場合、問題がゆっくりと発生する可能性があります。 以前にdefer db.close()を呼び出していた場合、このようなものは検出されない可能性がありますが、以前のコードが使い捨てであることに基づいて、まったく新しいプールが作成/開かれている場合があるように思われますスタイルの。

データベース接続の待ち時間がそれほど悪くなく、後でプールの割り当てが正常に解除される限り、各リクエストメソッドでの開閉も機能しますが、ほとんどの設定では、2つの別々のアプリケーションがない限り、プールを使用する方が良いと思います。 t（たとえば）多くの接続を長期間開いたままにしておくと、アイドル状態であっても、他の接続が一部を割り当てるのをブロックする可能性があります。

@dgryskiええ、私もそう思っていました（上記を参照）。 単一の使用から保持されたプールへの切り替え中に、別のプールがコードのどこかに作成されていて、割り当てが解除されていない場合などがあります。

関連する別の問題：

以前の方法では、デバッグの目的でこれを行うために使用します（外部キー制約エラーを回避するため）。

db.Exec("SET foreign_key_checks = 0;")
_, err := db.Exec("INSERT IGNORE INTO " + c.Q_VALENTINES_PIVOT_CUSTOMER_EVENT + " (customer_id, event_id, gender, allocated_group, session_1, session_2, public_name, profile_photo, registered_time) VALUES " + values + ";")
    if err != nil {
        db.Exec("SET foreign_key_checks = 1;")
        return err
    }
    db.Exec("SET foreign_key_checks = 1;")

それは常に動作するために使用します。

「接続プール」を使用しているので、これは機能しません。
https://github.com/go-sql-driver/mysql/issues/208 ：これが理由を説明しています。 同じ接続を使用するという保証はなく、 SETはセッションにのみ設定されているため、必ずしもメインステートメントに適用されるとは限りません。

という事は承知しています。 しかし、どうしてそれが私の以前の方法で機能したのでしょうか。 私は常に新しい接続を作成し、要求サイクルの終わりにそれを閉じましたが、作成した「接続」は引き続き接続プールを利用しますか？

@pjebs接続プールは複数の接続を開く可能性があります。 一度に1つの接続のみが必要な場合は、1つの接続を維持します。 以前のケースでは、同じプールで2つのデータベース要求が同時に発生したことはなかったため、1つの接続しか確立されませんでした。 したがって、すべてのExecは同じ接続で発生しました。 適切なプールに移動すると、これは当てはまりません。

より多くのコードを見ることができれば、これはデバッグが容易になります。

@pjebsデータベーストランザクションとしてこれを実行して、同じ接続に確実にヒットするようにする必要があります：http： //jinzhu.me/gorm/advanced.html#transactions

なぜそれがあなたの言うことをしているのかはわかりませんが、ステートメントの要求ごとに異なる接続を使用することは完全にラインから外れているわけではありません。 これは「プール」の背後にある一種の考え方です...リクエストを行っているものが必ずしもわからず、同時に動作するリクエストが多数存在する可能性があることを考えると。 単一の接続がその存続期間全体にわたって単一の要求のために予約されるのはちょっとばかげているでしょうが、そうです。 トランザクションを使用します。

トランザクション内で接続を交換することは完全にラインから外れます。 構成パラメーターを変更すると、コードの他の部分からの他のクエリや他の要求に影響を与える可能性があるため、実行していることは実際にはトランザクション内にある必要があります。 現在書かれている方法...コードがパニックになった場合、その特定の接続で元に戻されることはありません！ その点で、トランザクションが終了しない場合（たとえば、クラッシュ/パニックが発生した場合）は、トランザクションのロールバックを延期するようにしてください。そうしないと、データベース接続がハングしたり、別のプロセスがそのデータベース接続を採用して開始したりする可能性があります。コミットされないようなトランザクションへの変更など— https://github.com/jinzhu/gorm/issues/1056

@broadyのコードで気づきました： https ：//github.com/GoogleCloudPlatform/golang-samples/blob/master/getting-started/bookshelf/db_mysql.go#L82
接続を開いた後、すぐにPing()を呼び出して、接続がまだ応答しているかどうかをテストします。
そうでない場合、彼はただやめます。 他にできることはありますか？ もう一度開いてみるべきですか？

https://godoc.org/github.com/garyburd/redigo/redis#Poolライブラリでは、優れたプールも実装されています。
TestOnBorrowという優れた関数があり、少し下の例ではPing()も実行します。

このドライバーに似たようなものはありますか？

@pjebs実際の現在の問題は何ですか？

Ping()を実装するタイミングと、Pingが失敗した場合の対処方法に関するベストプラクティスについて尋ねるだけです。

ああなるほど。 私が知る限り、あなたはそうする必要はないはずです...？ しかし、プールにまだ接続が切断されている場合は...必要と思われます。

間違いなくPingする必要があります。 彼らはredigo （リンクの上）と@broadyのコードでそれを行います。

db.Exec("SELECT 1+1")はPINGとして使用できます。

また、 https：//golang.org/pkg/database/sql/#DB.Ping

「間違いなく」Pingする必要がありますか？ それは意味がありません...接続が有効でない場合はどうなりますか？ 中止しますか、それとも再試行しますか？

.Ping相当するクエリ呼び出しを自動的に実行しないのはなぜですか？

db.Exec（ "SELECT 1 + 1"）はPINGとして使用できます。

では、なぜ私たちは間違いなく.Pingする必要があるのでしょうか。

Pingは、接続と認証が有効であることを検証します。 最初のリクエストよりも、プールの確立に失敗したほうがいいと思います。

再試行できると思いますが、回避している障害状態は何ですか？ 悪いネットワーク接続？

@benguild db.Ping()はこのライブラリを使用しません。
ゴーナッツやフォーラムに行くのはどうですか？

はい、時々、返されたプールされた接続の1つが不良です。 現在、私はpingを呼び出し、pingが失敗した場合は、明示的にcloseを開いてから、クエリを開いて再試行します（ドキュメントに記載されているように、このライブラリのpooling機能でそれが意図されているかどうかはわかりません。選ぶ。

@broady 、わかりました。もっと理にかなっています... [プール]に留まるとは思わなかったし、プールから発信者への接続が切断されたとは思いませんでした。 @pjebs参考までに、私たちは両方ともGORMを使用していることを知っています、そしてそれは実際にはgorm.Open()の終わりにこれを行います：

if err == nil {
    err = db.DB().Ping() // Send a ping to make sure the database connection is alive.
}

OK、この特定のライブラリが.Pingを試行することを考慮しますが、それ以外の場合は失敗した場合に再試行しません（単にエラーを返します）....妥当なレベルの場合、このようなものが必要になる可能性がありますこのドライバーとの整合性？

for databaseConnectionAttemptLoop := 0; databaseConnectionAttemptLoop<4; databaseConnectionAttemptLoop++ {
    err=nil; // NOTE: If there is an error, the loop will continue and replace the value for "err" with each attempt. This will continue until the maximum number of attempts have been made... at which point the loop simply exits and the error is returned at the end of the function.

    if db, err = gorm.Open(/* database connection string... NOTE: This function attempts `.Ping` on its own. */))); err == nil && db != nil {
        /* configure connection */

    }
    ////

    if (err==nil) {
        break; // Here, if there is no error, it simply breaks out and does not retry again.

    }

}

悪い接続が意図的に返される可能性がある場合、現在何が期待されるかはわかりません。

現在、Pingが失敗した場合（通常は接続不良が原因）、各試行の間にわずかなtime.sleep()を置いて、再接続を試行するときに無限ループを実行します。 Google App Engineは、60秒のリクエストウォッチドッグタイマーの期限が切れるとリクエストを破棄するため、実際の無限ループの危険はありません。

うーん、そうするかどうかはわかりません—
time.sleep()は良さそうに聞こえますが、最大5回程度試してみます。 ボックスが合法的にダウンまたは過負荷になっている場合、60秒間ハングしているリクエストが多いと、Webサーバーがクラッシュしたり、使用料が高額になる可能性があります。

それが私が現在テストのために行っていることです。 実稼働環境では実行されません。 試行回数に制限を設けます。
ありがたいことに、私は1分以上クラウドSQLがダウンしているのを見たことがありません。

GoogleのSREブックは、ランダム化された指数バックオフで最大3回の試行を提案しており、プロセスごとのグローバルな再試行予算は10％です。 通話の10％以上が失敗し始めた場合は、再試行を停止してください。

ああすごい。 ありがとう@dgryski 。 SREの本はどこにありますか？

https://books.google.com.au/books?id=81UrjwEACAAJ&redir_esc=y
私はそれを買わなければならないようです。

@dgryski 「グローバルなプロセスごとの再試行バジェット」とはどういう意味ですか？

@ベンギルド

db.DB().SetConnMaxLifetime(time.Minute*5);
db.DB().SetMaxIdleConns(0);
db.DB().SetMaxOpenConns(5);

このスニペットコードを使用して、複数のgoruntimeを使用すると、エラーが発生しました

(dial tcp 127.0.0.1:3306: connect: can't assign requested address)

https://github.com/jinzhu/gorm/issues/1898を参照してください

接続が開いたらすぐにこれらを呼び出してみてください。

db.DB().SetConnMaxLifetime(time.Minute*5);
db.DB().SetMaxIdleConns(5);
db.DB().SetMaxOpenConns(5);

それを解決します。

1年以上の間、リクエストの開始時にOpen()を使用し、リクエストのライフサイクルの終了時にClose()を使用して、このドライバーを使用してきました。 それは完璧に機能しました。

このアドバイスを聞いて、私は1つの接続を開き、参照をグローバル変数に残して、それを使い続けます。 私はそれを決して閉じません。

SetConnMaxLifetime 、 SetMaxIdleConns 、 SetMaxOpenConnsを設定していません。 それらはデフォルトのままです。

この単純なテクニックは私にはうまくいきません。 CloudSQLへのアクティブな接続の数は、Google AppEngineの接続制限に達するまで増え続けます。 その後、データベースに接続できなくなります。

接続が閉じられていません。

proxysqlへの接続で同じ問題が発生します。 高負荷の本番ノードに次の構成を設定しました。

max_idle: 1
max_open: 100
max_life_time: 5s
write_timeout: 5s
read_timeout: 3s
connection_timeout: 10s

しかし、dbポートの接続数を確認すると、 TIME_WAIT状態で21kを超える接続が表示されます。