GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
MySQLを7000インスタンス規模で運用するLINEは、MySQL互換のNewSQLをどう評価したか？［PR］
MySQLを7000インスタンス規模で運用するLINEは、MySQL互換のNewSQLをどう評価したか？［PR］ コミュニケーションアプリ「LINE」をはじめ、多くの大規模サービスを運営するLINE株式会社は、LINEマンガやLINE GAME、LINEギフトなどをはじめとするLINE関連サービスのデータベース基盤として約7000ものMySQLインスタンスを運用しています。 このMySQLインスタンスの国内における管理と運用を行っているのが、MySQLコミュニティでも活躍する国内トップクラスのMySQLエキスパートを含む7名のITエンジニアで構成される「MySQL1チーム」です。 同チームのマネージャーである北川健太郎氏は、LINE関連サービスの発展に伴って増大するMySQLインスタンスの運用管理という課題に、日々のオペレーションの自動化を実現するための開発を積極的に行うことで対応している
さよなら本番サーバー - Qiita
とあるSESの現場では本番リリースの時期が近づいてきており、僕を含めた数人のエンジニアは間に合いそうもない残作業の開発を進めたり、本番で使うためのデータの整備を本番サーバー内で行ったりしていた。ほとんどがその案件のために集められたメンバーだったため特に和気あいあいとするでもなく、エアコンの風の音が響く小さなオフィスの片隅で静かに作業をしていた。 業務上のやりとりもRedmineで行われており、声を発するのもたまにメンバー同士で話をしたり、クライアントから電話がかかってきた時だけ。その日もメールで通知が届いてきており、確認してみるとRedmineで僕が関係しているチケットにコメントが届いているという通知だった。 通知のURLをクリックしてRedmineのチケットを確認してみる。 それによると一旦本番サーバー上に存在するデータの中の一部の主要データをCSV形式で送ってほしいという依頼だった。無
ちゃんと復旧できる、GitLabのバックアップ運用方法 ─ GitLab meetup #01レポート - pixiv inside
2017年3月2日（木）、都内では初のGitLabのイベント「GitLab meetup in Tokyo #1」が開催されました。記念すべき第一回のイベントは、ピクシブのオフィスで開催され、約140名の参加があるという大盛況っぷり。ピクシブからは、2名のエンジニアが登壇しGitLabに対する知見を発表しています！ そのうちの一人。2013年にピクシブへ入社した金子 達哉、ニックネームはcatatsuy。彼が同イベントで語った、GitLabのバックアップや、バージョンアップの運用に関する知見を、本記事にてご紹介します。 GitLabのインストールは難しい？ GitLabとは、プライベートなgitリポジトリの管理画面やレビュー画面を提供してくれるWebアプリケーションです。GitHubやBitbucketのようなことが、自社のサーバで行えます。自社のサーバーにインストールして運用することがで
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
