並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 29 件 / 29件

新着順 人気順

replicationの検索結果1 - 29 件 / 29件

  • MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク

      MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
    • MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ

      こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo

        MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ
      • 人気順検索のSolrはスケールのためにディスクを捨てた - クックパッド開発者ブログ

        技術部クックパッドサービス基盤グループの id:koba789 です。 昨年まではデータ基盤グループというところで 最新のログもすぐクエリできる速くて容量無限の最強ログ基盤 を作ったりしていました。 今年はちょっとチームを移動しまして、検索システムをいじっていました。今回はそのお話です。 なお、クックパッドには様々な検索システムがありますが、この記事では説明を簡単にするためにレシピの検索のみに焦点をあてています。 クックパッドの検索システムにあった課題 クックパッドにはレシピを検索できる機能があります。 プレミアム会員限定の人気順検索もこの機能の一部です。 しかし、この重要な機能を支える検索システムにはいくつもの課題がありました。 Solr が古すぎる クックパッドでは、レシピ検索を含む多くの検索機能にSolrを用いています。 今年の始めに私がこの課題に取り組み始めた時点では、その Sol

          人気順検索のSolrはスケールのためにディスクを捨てた - クックパッド開発者ブログ
        • BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場

          BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場 Google Cloudは、BigQueryに対してMySQLやPostgreSQL、Oracle Databaseからニアリアルタイムで直接データのレプリケーションを可能にする新サービス「Datastream for BigQuery」をプレビューリリースしました。 オンプレミスやクラウドで稼働するMySQLやPostgreSQL、Oracle DatabaseでのOLTPによるデータ操作が、ETLツールなどを挟むことなくほぼリアルタイムでBigQueryに反映されるため、プライマリとなるデータベースのOLTP処理に負荷をかけることなく並行してBigQueryによる大規模データの分析処理が容易になります。 To stay compet

            BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場
          • Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog

            SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯(ステージング環境を後から立てたり!)から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a

              Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
            • 「複雑すぎるサーバー構成」を原点にまで簡素化する「Litestream」が生まれた理由

              現代のシステムでは、冗長化や負荷分散の観点から、複数のサーバーにサービスを分離することが当たり前となりました。しかし、キャッシュやキューの乱用など、システム構成が必要以上に複雑化している場合もあります。「複雑化したサーバー構成」を簡素化すべく、Goのローカルデータベースとして知られるBoltの開発者・ベン・ジョンソン氏が生み出したのが「Litestream」です。 Why I Built Litestream - Litestream https://litestream.io/blog/why-i-built-litestream/ ジョンソン氏が「古き良き時代だが、実のところは最悪な時代」と語る数十年前は、単一のプログラミング言語とSQLの知識があればどんな開発現場でも通用し、すべてのウェブサイトが基本的なHTML技術で作成されていた時代だったとのこと。1990年代後半には「Linux

                「複雑すぎるサーバー構成」を原点にまで簡素化する「Litestream」が生まれた理由
              • RDS Proxyを用いたオンラインスイッチオーバーによるMySQLのアップグレードについて - freee Developers Hub

                おはこんばんちは、DBREの橋本です。 今回は、Amazon RDS Proxy(以降RDS Proxyとよぶ)を用いたRDS for MySQLインスタンスおよびAurora MySQLクラスタのオンラインスイッチオーバーの手法について、ある程度社内での運用が確立してきましたので解説いたします。 従来のアップデート手法 AWS上でRDS for MySQLインスタンスやAurora MySQLクラスタ(以降これらをデータベースとしてまとめてよぶ)を運用している場合、それらのエンジンバージョンの更新を行ったり、OSバージョンの更新に伴う再起動を実施する必要があります。これらの更新を行う場合、以下のような方法が考えられます。 対象のデータベースに直接更新を適用する スナップショットを作成し、更新済みのデータベースとして復元する 更新済みの空のデータベースを新規作成し、そちらにデータを移行し、

                  RDS Proxyを用いたオンラインスイッチオーバーによるMySQLのアップグレードについて - freee Developers Hub
                • Litestream - Streaming SQLite Replication

                  Stop building slow, complex, fragile software systems. Safely run your application on a single server. Fully-replicated database with no pain and little cost. Get started Join our Slack No-worry backups Continuously stream SQLite changes to AWS S3, Azure Blob Storage, Google Cloud Storage, SFTP, or NFS. Quickly recover to the point of failure if your server goes down. Use existing apps Runs as a s

                    Litestream - Streaming SQLite Replication
                  • MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ

                    サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M

                      MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
                    • GitHub - superfly/litefs: FUSE-based file system for replicating SQLite databases across a cluster of machines

                      You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                        GitHub - superfly/litefs: FUSE-based file system for replicating SQLite databases across a cluster of machines
                      • レプリケーションとは、仕組み~3つのお勧めケースまで総解説

                        メリット1:システムを止めずに業務継続を可能にする複製元(稼働系)から複製先(待機系)にリアルタイムにデータを複製することで、稼働系にシステム障害が起こっても、待機系へ切替えることで復旧が可能となり、ダウンタイム(システムが停止している時間)を最小限に抑えられます。 メリット2:システムへの負荷分散ができる例えば、データベースの規模が大きかったり、アクセス頻度が高いといった場合、サーバーに過度の負荷がかかり、処理ができずサーバーがダウンする可能性がありますが、複製側のサーバーを参照用にしたり、データ解析用途では複製側のサーバーで処理を行うなど、アクセスを分散させることによって負荷を軽減し、全体のパフォーマンスを向上させることができます。 メリット3:サーバー移行の時間短縮になるサーバーの移行でも、できるだけ業務を止めずに簡単に済ませたいものです。レプリケーションを利用することで、システムを

                          レプリケーションとは、仕組み~3つのお勧めケースまで総解説
                        • Redis の Slave (Replica) の Expire は 4.0 RC3 以降信用して良くなっている - その手の平は尻もつかめるさ

                          maedama.hatenablog.com trapezoid.hatenablog.com 上記のブログには今から6年ほど前の当時の情報が記されていますが,Redis 4.0 RC3 以降の Slave (replica) の Expire は信用して良くなっているようです. Redis の公式ドキュメント (Replication – Redis) を参照すると, However note that writable replicas before version 4.0 were incapable of expiring keys with a time to live set. This means that if you use EXPIRE or other commands that set a maximum TTL for a key, the key will le

                            Redis の Slave (Replica) の Expire は 4.0 RC3 以降信用して良くなっている - その手の平は尻もつかめるさ
                          • マルチスレッドレプリカにおける運用時の注意点について

                            はじめに 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

                              マルチスレッドレプリカにおける運用時の注意点について
                            • 10 Things I Hate About PostgreSQL

                              PostgreSQL performance degrades rapidly with more connections. Credit: brandur.org. Over the last few years, the software development community’s love affair with the popular open-source relational database has reached a bit of a fever pitch. This Hacker News thread covering a piece titled “PostgreSQL is the worlds’ best database”, busting at the seams with fawning sycophants lavishing uncondition

                                10 Things I Hate About PostgreSQL
                              • マルチクラウド構成におけるMySQL Group Replicationの利用事例紹介

                                こんにちは、滝澤です。 前回の記事『WireGuardによるマルチクラウド構成VPNの事例紹介』に引き続き、社内事例を紹介します。 弊社ハートビーツではMSP(Managed Service Provider)サービスの可用性向上のために、社内基盤をマルチクラウド構成で運用しています。 複数のクラウド拠点のネットワーク間をWireGuardというVPNトンネルのソフトウェアで接続しています。 さらに、リレーショナルデータベース管理システムにはMySQLを利用しており、MySQLのレプリケーション機能の一つであるGroup Replicationを使って拠点内および拠点間における冗長化を行っています。 今回はこのMySQL Group Replicationの利用事例を紹介します。 行っていることをまとめると次のようになります。 マルチクラウド構成(Azure, AWS, GCP)において、

                                • AWS Aurora MySQL v5.6 から v5.7 へのアップグレードをちょっとだけ考えてみた - mita2 database life

                                  Aurora MySQL v5.6 のサポート期限がいつかわからない 現在、Auroraでは、MySQL v5.6 (Engine 1.x) とv5.7互換 (Engine 2.x) のデータベースが利用できます。 Oracleが開発しているオリジナルのMySQL v5.6(以降 Vanilla MySQLと記載) は、2021/02 にサポートが切れます。 Aurora MySQL は Amazonが独自に開発している互換DBです。Vanilla MySQLのサポート期限はAuroraには関係ないのですが、互換DBであることを踏まえると、 「同じようなタイミングでサポート切れになる可能性もあるのでは・・・」と心配になってしまいます。 例えば、RHEL6互換のAmazon LinuxはRHEL6のサポート期限(2020/11末)と近しいタイミングでサポートが終了になっているようです。 aw

                                    AWS Aurora MySQL v5.6 から v5.7 へのアップグレードをちょっとだけ考えてみた - mita2 database life
                                  • MySQLのレプリケーション設定で起きたトラブルの原因とその解決策

                                    そのため、binlog_formatの設定を合わせるため問題が起こったのsourceサーバーをSTATEMENTにして対処したところ、今度は更新処理で以下のようなエラーが出ていました。 ERROR 1665 (HY000): Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.これによりsourceに書き込む

                                      MySQLのレプリケーション設定で起きたトラブルの原因とその解決策
                                    • Aurora MySQLからCloud SQLへのレプリケーション構築における注意すべき2つのポイント - ZOZO TECH BLOG

                                      こんにちは、MA部でエンジニアをしている田島です。 以前に弊社の塩崎が「Amazon AuroraのデータをリアルタイムにGoogle BigQueryに連携してみた」という発表を行いました。 こちらの発表では、Amazon Aurora MySQLのデータをGoogle BigQueryへリアルタイムにデータ連携する方法を紹介しています。リアルタイムデータ連携を実現するために、Aurora MySQLをレプリケーションソースとしてGoogle Cloud SQLへレプリケーションします。そして、BigQueryのFederated Query機能を利用してリアルタイムにデータを参照できるようにしています。 本記事ではその中の、Aurora MySQLからCloud SQLへのレプリケーション部分にフォーカスします。Aurora MySQLがマネージドサービスだからこそ発生する大きな注意ポ

                                        Aurora MySQLからCloud SQLへのレプリケーション構築における注意すべき2つのポイント - ZOZO TECH BLOG
                                      • PowerSync: Drop-in sync layer for offline-first apps

                                        “Integrated @powersync_ into an experimental branch of @HabitKit. Setup was pretty easy and fast. Really love the developer experience and I'm amazed how good it works 🤩”

                                          PowerSync: Drop-in sync layer for offline-first apps
                                        • GitHub - zknill/sqledge: Replicate postgres to SQLite on the edge

                                          You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                            GitHub - zknill/sqledge: Replicate postgres to SQLite on the edge
                                          • レプリケーションソフトDRBD9の特徴と改善点 | SIOS Tech. Lab

                                            ◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました 生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!! https://tech-lab.connpass.com/event/315703/ DRBDとはDRBDは、ストレージのレプリケーション(複製)のためのソフトウェアです。サーバ間でブロックデバイス(ハードディスク、パーティション、論理ボリュームなど)の内容をミラーします。 DRBDによるミラーは次の

                                            • Amazon RDS Online Seminar 「忘れちゃいけない!Amazon RDS/Amazon Aurora のアップグレードとその方法」資料・動画及び QA 公開 | Amazon Web Services

                                              Amazon Web Services ブログ Amazon RDS Online Seminar 「忘れちゃいけない!Amazon RDS/Amazon Aurora のアップグレードとその方法」資料・動画及び QA 公開 先日(2021/6/17) に開催した Amazon RDS Online Seminar「忘れちゃいけない!Amazon RDS/Amazon Aurora のアップグレードとその方法」の資料・動画を公開しました。 当日、参加者の皆様には数多くの QA を頂きありがとうございました。頂いた QA の一部についても共有しております。 【動画】 Amazon RDS/Aurora Update RDS for PostgreSQL/Aurora PostgreSQL upgrade (major/minor version up) RDS for MySQL/Auror

                                                Amazon RDS Online Seminar 「忘れちゃいけない!Amazon RDS/Amazon Aurora のアップグレードとその方法」資料・動画及び QA 公開 | Amazon Web Services
                                              • オブジェクトのレプリケーション - Amazon Simple Storage Service

                                                レプリケーションを使用すると、Amazon S3 バケット間でオブジェクトを自動で非同期的にコピーできます。オブジェクトのレプリケーション用に設定されたバケットは、同じ AWS アカウント が所有することも、異なるアカウントが所有することもできます。オブジェクトは、単一または複数の送信先バケットにレプリケートできます。送信先バケットは、異なる AWS リージョン でも、ソースバケットと同じリージョン内でも配置することができます。 新しいオブジェクトをバケットに書き込むときに自動的にレプリケートするには、クロスリージョンレプリケーション (CRR) などのライブレプリケーションを使用します。オンデマンドで既存のオブジェクトを別のバケットにレプリケートするには、S3 バッチレプリケーションを使用します。既存のオブジェクトのレプリケーションの詳細については、「S3 バッチレプリケーションを使用す

                                                • Oracle Databaseレプリケーションとサポート状況/対応製品 | コーソルDatabaseエンジニアのBlog

                                                  渡部です。Oracle Database関連のレプリケーション技術について整理します。 Oracle Database本体のレプリケーション機能の多くが、サポートが終了していることに注意してください。 物理レプリケーションと論理レプリケーション データベースのレプリケーション技術は、物理レプリケーションと論理レプリケーションに大別されます。 物理レプリケーションは、データベース全体に対する物理的な更新を伝搬することで、 データベースを複製します。レプリケーション元のデータベース(プライマリDB)と レプリケーション先のデータベース(スタンバイDB)の物理的な構造が同じになります。 メカニズムがシンプルで運用しやすいため、災害対策に向けたDR構成/HA構成によく使用されます。 論理レプリケーションは、指定したテーブル群に対する論理的な更新を伝搬することで、 データベース内の指定したテーブル群

                                                  • MySQLを止めずにレプリケーションをブーストする小技 - mita2 database life

                                                    先日は、MySQLユーザ会会 2020年7月に参加しました。 今回はWebや雑誌で連載の著者の方々が、執筆に至った経緯や、執筆時に心がけていることを語る回でした。 @kk2170 さんが「過去の自分に向けて書く」とおっしゃっていたのが、(そういう視点は自分の中になかったので)すごく響きました。 mysql.connpass.com -- 一刻も早くレプリケーション遅延を取り戻したい!そんな場合に使える小技を紹介します。 レプリケーションを止めずに有効化・無効化できるのみを取り上げています。 元に戻すのにレプリケーションを止める必要性のある方法だと、またそこでレプリケーション遅延が発生しますからね… CPU の governor を performance に変更する LinuxにはCPUクロックの調整機能があり、CPU governor が ondemand 設定の場合、負荷に応じて、CP

                                                      MySQLを止めずにレプリケーションをブーストする小技 - mita2 database life
                                                    • AWS Database Migration Service とは - AWS Database Migration Service

                                                      翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS Database Migration Service とは AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、その他の種類のデータストアを移行できるようにするクラウドサービスです。AWS DMS を使用して、データの AWS クラウド への移行や、クラウドとオンプレミスセットアップを組み合わせたものの間でのデータ移行ができます。 AWS DMS を使用すると、ソースデータストアの検出、ソーススキーマの変換、データの移行ができます。 ソースデータインフラストラクチャの検出には、DMS Fleet Advisor を利用できます。このサービスは、オンプレ

                                                      • vCenter Serverが無くても出来る!仮想マシンのコピー方法 - 一馬力のメモ帳

                                                        VMware vSphereを利用していると 「仮想マシンをちょっとコピーして使いたい」 って時ありますよね? vCenter Serverが利用できる環境であれば 「クローン」を作成する事で実現できますが ESXi単体で利用しているときはクローンが利用できません https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.hostclient.doc/GUID-5C504B67-CDB3-42FC-8B3B-737201A725DD.html vCenter Serverがない環境で仮想マシンをコピーする場合は エクスポート→インポートでコピーする方法をとります。 今回はVMware Host Clientを利用して エクスポート→インポートで仮想マシンをコピーする方法を紹介します。 目次 目次 仮想マシンのエクスポー

                                                          vCenter Serverが無くても出来る!仮想マシンのコピー方法 - 一馬力のメモ帳
                                                        • Multi-Master Replication Solutions for PostgreSQL

                                                          Due to the immense generation of data, scalability has become one of the hottest topics in the field of databases. Scalability can be achieved horizontally or vertically. Vertical scalability means adding more resources/hardware to existing nodes to enhance the capability of the database to store and process more data, for example, adding a new process, memory, or disk to an existing node. Every D

                                                            Multi-Master Replication Solutions for PostgreSQL
                                                          • ロジカルレプリケーションのレプリケーション衝突を解決する

                                                            ざっくりまとめると、 PostgreSQLのロジカルレプリケーションでレプリケーション衝突が起こった場合、衝突が(手動で)回避されるまでスタンバイでの反映が止まる 衝突を回避するための一つの方法として、pg_replication_origin_advance()関数を使って衝突の原因となるWAL(を送信する事)をスキップできるけど、スキップ先のLSNを指定するので他の必要なデータもスキップしてしまうかもしれないよ ということ。 レプリケーション衝突というのは、データの受信側(Subscriber)でのデータを適用と、テーブル内のデータや受信側で実行中の変更内容が衝突する事を指しています。 試してみる 実施にやってみる。まずは、テーブルを作成して、ロジカルレプリケーションを開始。 -- 上流側(Publisher) =# CREATE TABLE test (c int primary k

                                                            1