XRP Ledger（XRPL）はネットワークの問題を解決することを目的としたアップグレードを受ける予定です。 このアップグレードを促した主要な問題は、完全な履歴（FH）ノードが、ページサイズのSQLite制限によって失敗することでした。
XRPのdUNLバリデータであるVetは、この開発をXの投稿で共有しました。Vetによると、XRP Ledger Full History Serversの問題の修正がXRPLFリポジトリの公式リップルリリースでマージされました – リップル2.2.3。このバージョンは現在、インストールが可能です。
ベットによって共有されたスクリーンショットによると、リップル社の（XRPレジャーサーバー）バージョン2.2.3リリースは、ページサイズ4096を使用するフルヒストリーサーバーに強く推奨されています。バリデータはこの問題の影響を受けていないため、2.2.2を実行するか、2.2.3にアップデートすることを選択できます。これは、バージョン2.2.3がバージョン2.2.2に新しい改正を導入していないためです。
「何があったの？」
週末に、XRPコミュニティは、フルヒストリー（FH）ノードの障害を引き起こすリップルサーバー上の問題に注目しました。
通常の状況では、フルヒストリーサーバーは喜んで完全な取引履歴を記録して提供します。しかし、FHノードはページサイズに関するSQLiteの制限により失敗しました。
いくつかのXRPL dUNLバリデータによると、数週間前にこの問題が強調されましたが、迅速な対応を確保することに失敗しました。
XRP Cafeの創設者であるxrpl Adamは、Xポストで明確にしたところによると、一般的に信じられていることとは対照的に、この問題はコンセンサスやネットワークの健全性に影響を与えないと述べました。
この文を日本語に言い換えると、「この文章を日本語に変換してください」となります。
さらに、クリオの冗長性により、ほとんどの公共XRPLエンドポイントは、過去の取引結果を返すために実際のFHサーバーを必要としません。
Xrpl Adamによると、XRP Ledgerにおけるこの問題は新しいものではなく、数年前に文書化されていました。当時、完全な台帳履歴を持つ特定のrippledサーバーは、SQLiteデータベースのページサイズの問題に直面し、サーバーの正常な動作を妨げる可能性があることが指摘されていました。
しかし、XRP Cafeの創設者は、対処が急を要する重要性がもっと早く促進されるべきだったと考えており、週末に発生したFHノードのダウンを避けるべきだったと信じています。
