デバッグ(?)レコード-DBリカバリ、Sentry
DB 복구
運営するサービスデータベースを破壊する事故が発生しました...
ロードテストを行うためにテスト用DBとアプリケーションサーバを起動し、テストのたびにテーブル初期化を設定しています.でも.envのホスト情報が更新されていないため、本番データベースのデータはすべて失われています.3日後になってやっと知ったのですが、ちょっとしたサービスでしたが、冷や汗をかきました.
幸いなことに、RDSの自動バックアップが有効になり、事故の前日にDBにリカバリでき、その後のデータはクエリーとハードコーディングでリカバリできます.RDSを使用すると、バックアップとリカバリが容易になりそうです.既存機器でDB実装後のフローティング方式を継続して使用していると回復できない恐れがあります.
後でこのようなことが起こらないようにDBユーザの権限を変更する.
REVOKE DROP ON *.* FROM 'username'@'%';
これ以上うるさくてGRANTALLはできないまた,ユーザ名,パスワードなども作成とテストが常に異なることを望んでいる.
Sentry 를 통한 디버깅
サービスの導入と表示は、開発段階で予想外のエラーが発生します.初めて配布された後、店のコメントだけがエラーが発生したことを知ることができます.
上のようにずっとエラーが発生していますが、目覚まし時計がないので、エラーが長く続くことがよくあります.単独記録もないので、なぜエラーが発生したのかを特定するのは難しい.
そこで、Sentryというエラーモニタツールを使用することにした.
NestJSのブロッキングを使って簡単に適用できます.
import {
Injectable,
NestInterceptor,
ExecutionContext,
CallHandler,
} from '@nestjs/common';
import { Observable } from 'rxjs';
import { catchError } from 'rxjs/operators';
import * as Sentry from '@sentry/node';
@Injectable()
export class SentryExceptionInterceptor implements NestInterceptor {
intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
return next.handle().pipe(
catchError((error) => {
Sentry.captureException(error);
throw error;
}),
);
}
}
const app = await NestFactory.create(AppModule);
app.useGlobalInterceptors(new SentryExceptionInterceptor());
その後、Sentryアプリケーションで設定エラーが発生した場合にメールでアラートを送信します.発生したエラー
適用後ずっとヒントがあったので確認したらtaskが生成できないエラーがありました.同じエラーが現地で発生したと思っていたのですが、どうしてもダメだったので、しばらく保留しておきました.
しかしアラームが鳴り続けて放置できなかったので再確認してみると、失敗したリクエストのオペレーティングシステムはすべてアンドロイドシステムでした.だから私はアンドロイドvmを置いて、少しかき回して、よく考えてみると、これはオペレーティングシステムの問題ではありません.
taskは常に親に属し、部分は常にプロジェクトに属します.だから最初のプレイヤーは生成時に基本アイテムと基本部分を生成します.しかし、いずれコードを修正する過程で基本部分を生成する部分が漏れてしまう.すぐに修正し、テストコードも更新しました.
テストケースをもっと細かく作成すれば、このエラーは予防できるようです.
Reference
この問題について(デバッグ(?)レコード-DBリカバリ、Sentry), 我々は、より多くの情報をここで見つけました https://velog.io/@shkilo/디버깅-기록-DB복구-Sentryテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol