マルチスレッドレプリカにおける運用時の注意点について
はじめに 2021 年 10 月 19 日に MySQL 8.0.27 がリリース されました。非同期レプリケーションにおける変更点の 1 つとして、デフォルトでマルチスレッドレプリカが有効になり、レプリカの遅延を軽減しやすくなることが期待できるようになりました。 Replication: Multithreading is now enabled by default for replica servers. A multithreaded applier has a number of applier threads that execute transactions in parallel. This behavior can avoid many cases of unwanted replication lag that can cause temporary divergenc
Wrapping Errors the Right Way
I’ve seen a few examples of error handling like the following lately: func MightFail(id string) error { err := sqlStatement() if err != nil { return fmt.Errorf("mightFail failed with id %v because of sql: %w", id, err } ... return nil }See the problem? It becomes more clear when you start to use the function: func business(ids []string) error { for _, id := range ids { err := MightFail(id) if err
トランザクション中の文の失敗の扱いの違い - Write and Run
(読みづらいタイトルだな) ことの発端はこのツイート。 MySQLは、以下を満たさないという理解でいいのか？ エラーが出た時にPostgreSQLのようにロールバックを行わないので Atomicity（原子性）・・・トランザクションの実行結果は「全て成功」か「全て失敗」のいずれかでなければならない#mysql— imaharu (@imaharuTech) July 2, 2020 さすがの MySQL でもそこを破ってくることはないだろうと思いつつ、トランザクション野郎としてはちゃんと確かめねばならないと思い、早朝にも関わらず布団から出てラップトップを開いた(午前10時)。 実験1 以下のような docker-compose.yml と sql/script.sql を用意し、実験をする。 version: '3.3' services: db: image: mysql:8 envir
Nuxt.js(Vue.js)とGoでSPA + API(レイヤードアーキテクチャ)でチャットアプリを実装してみた - Qiita
概要 Nuxt.js(Vue.js)とレイヤードアーキテクチャのお勉強のために簡単なチャットアプリを実装してみた。 SPA + APIと言った形になっている。 機能 機能はだいたい以下のような感じ。 ログイン機能 サインアップ機能 スレッド一覧表示機能 スレッド作成機能 ログインしたユーザーは誰でもスレッドを作成できること コメント一覧表示機能 スレッドをクリックすると、そのスレッド内のコメント一覧が表示されること スレッド内でのコメント作成機能 ログインしたユーザーは誰でもどのスレッド内でもコメントできること スレッド内でのコメント削除機能 自分のコメントのみ削除できること ログアウト機能 コード コード全体はここ コードは一例でもっと他の実装や良さそうな実装はありそう 技術 サーバーサイド DDD本に出てくるレイヤードアーキテクチャをベースに以下の書籍や記事を参考にさせていただき実装し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
