1CフレッシュのDBMS。 早く。 信頼できる。 無料で

このボタンは、会計データベースを操作するために、出版技術1C Freshを数年間使用しています。 最近、私たちの営業経験について書きました 。 私たちをDBMSとして使用するPostgreSQLは、関心と多くの質問を引き起こしました。そこで、私たちはこれについてさらに詳しく話すことにしました。

はじめに

最初は、従来の1C MS SQL ServerをDBMSとして使用しました。 Freshが水平スケーリングの必要性に成長すると、経済的な理由から、マイクロソフトの製品に代わるものが必要であることが明らかになりました。 その後、特に1Cの専門家が1C Freshのインストールでの使用を推奨しているため、PostgreSQLを注意深く検討しました。 標準操作のパフォーマンスを簡単に比較したところ、約600のエリアを含むエンタープライズアカウンティング（BP）3.0データベースも同様に機能することがわかりました。 その時点で、アプリケーションサーバーとDBMSを備えたLinux上の複数の仮想マシンのスキームに切り替えました。 これについては記事で少し説明しています 。 しかし、さまざまな理由で、1年後にWindows上のアプリケーションサーバーとLinux上のいくつかの情報ベース（IS）を備えたDBMSのスキームになりました。 しかし、Linux上のアプリケーションサーバーに問題がなかったことをあえて保証します。変更は他の機能の一部に関連しています。



そのため、PostgreSQLがデータベースサーバーとして選択されました。 この記事では、Buttonがどのようにしてお互いに友達を作り、どのように機能したのかを説明します。



最初のインストールでは、1Cが提供する既製のPostgreSQL 8.4.3-3.1C debパッケージを使用しました。これは、使用が推奨されるバージョンであったためです。 しかし、残念なことに、Debian Wheezyにインストールするときに依存関係の問題が発生しました。これは、当時のapache2.2パッケージを含む旧安定リリースでした（1Cではapache2.4のサポートはありませんでした）。 その時点では、DBMSとアプリケーションサーバーを同じホストに保持していたため、oldstableを使用する必要がありました。 このバージョンのPostgreSQLをインストールするには、Debian Jessieのlibc6が必要です。 このようなクロスオーバーの結果として、NFSクライアントをインストールしても作業に必要な依存関係が壊れた、特別なことは何もできないシステムが作成されました。 しかし、別のLinuxディストリビューションに切り替えることは、戦略的には有益ではありませんでした。 COM接続を介してアプリケーションサーバーとやり取りするマイクロサービス（簡単にするためにrobotsと呼びます）を積極的に使用し始めたとき、データベースにハングしている接続が現れ始め、メモリリークにつながりました。 この問題はPostgreSQLの新しいバージョンへの移行によって解決されましたが、その時点で1Cはこのバージョンのディストリビューションをまだリリースしていませんでした。



Postgres ProfessionalリポジトリからPostgreSQL 9.6ビルドを使用することに切り替えるという強い意思を決定しました。 依存関係とメモリリークの問題は取り残され、スケーラビリティ、負荷分散、および可用性時間の増加の問題に対処し始めました。 現在、1Cの専門家は、PostgreSQLビルド（最新の9.6.3）を既に更新しています。これは非常に最新のバージョンであり、使用する方が信頼性が高くなっています。 1Cからの情報によると、新しいアセンブリはすぐに発行されます。



現在、Debian Jessieに取り組んでおり、このディストリビューション内のすべての問題に引き続き対処します。



Zabbixを使用してシステムの状態を監視します。次のようになります。







チャートにはまだ古いサーバーがありますが、製品はすでにチャートからPostgreSQL 9.6に転送されています。



また、トランザクションの数も測定します。







そして、追加、変更、削除された行の数：







DBMSの運用では、パフォーマンスを慎重に監視し、以下のすべての設定は実際の運用と観察から正確に生まれました。 現在、2つのメインDBMSサーバーがあり、それぞれに8コアと40 GBのメモリが割り当てられています。 データベースのあるディスクはSSDにあります。 7 IS BP 3.0をデータ共有モードを有効にしてサービスを提供するのに十分なこれらのリソースがあります（1つのデータベースに200〜800エリア）。 この構成により、一方ではリソースを適切に利用し、他方では成長とピーク負荷に対して十分なマージンを達成しました。

PostgreSQLのクラスター

1台の仮想マシンに複数の情報セキュリティシステムを配置すると、管理の複雑さに直面しました。 各ISはサーバー設定を必要とし、DBMSをシャットダウンするとすべてのデータベースが切断され、WALアーカイブはまったく意味がありません。このメカニズムによる復元はサーバー上のすべてのデータベースをロールバックするためです。



まず、各データベースを個別のPostgreSQLクラスターに配置しました。これにより、データベースを柔軟に管理し、同じホスト上でPostgreSQLの独立したコピーをいくつか実行し、ストリーミングレプリケーション、WALアーカイブ、および特定の時点（PiTR）でのデータリカバリを構成できました。



実際には、展開プロセスは次のようになります。



Debian 8 Jessieがインストールされたマシンがあり、Postgres ProfessionalリポジトリからのPostgreSQL 9.6がすでにインストールされています。



新しいクラスターを作成しましょう：

# pg_createcluster 9.6 -p 5433 -d /databases/db_01
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、db_01ディレクトリが/データベースに作成され、データファイルと/etc/postgresql/9.6/db_01/の設定ファイルが含まれます。 クラスターはPostgreSQLのバージョン9.6を使用し、そのインスタンスはポート5433で起動されます。クラスターが実行されていないため、これはコマンドで確認できます。

 # pg_lsclusters
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスター構成ファイルpostgresql.confに変更を加えます。おおよそのパラメーター値はPgTuneを使用して取得できます。 このパラメーターまたはそのパラメーターの責任はドキュメントに詳細に記載されていますが、PgTuneが考慮しないパラメーターのみを説明します。



max_parallel_workers_per_gatherは、テーブルのシーケンシャル読み取りに並行して使用されるワーカーの数に等しい値を設定するのに役立ちます。 これにより、多くの読み取り操作が高速化されます。 ホストのコア数に基づいて、この数を超えてもパフォーマンスは向上しませんが、逆に低下が発生します。



max_locks_per_transactionはデフォルトで64ですが、操作中に値は300に引き上げられました。このパラメーターは、トランザクションごとに割り当てられたオブジェクトのロックの数を割り当てます。 スレーブサーバーを使用する場合、この値はマスターサーバーの値以上にする必要があります。



ファイルシステムの効率が十分でない場合は、pg_xlogを別のリポジトリに配置します。



たとえば、1つのクラスターの構成ファイル：

 # ----------------------------- # PostgreSQL configuration file # ----------------------------- #------------------------------------------------------------------------------ # FILE LOCATIONS #------------------------------------------------------------------------------ data_directory = '/db/disk_database_db_01/db_01' hba_file = '/etc/postgresql/9.6/db_01/pg_hba.conf' ident_file = '/etc/postgresql/9.6/db_01/pg_ident.conf' external_pid_file = '/var/run/postgresql/9.6-db_01.pid' #------------------------------------------------------------------------------ # CONNECTIONS AND AUTHENTICATION #------------------------------------------------------------------------------ listen_addresses = '*' port = 5433 max_connections = 100 unix_socket_directories = '/var/run/postgresql' ssl = true ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem' ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key' #------------------------------------------------------------------------------ # RESOURCE USAGE (except WAL) #------------------------------------------------------------------------------ shared_buffers = 1536MB work_mem = 7864kB maintenance_work_mem = 384MB dynamic_shared_memory_type = posix shared_preload_libraries = 'online_analyze, plantuner,pg_stat_statements' #------------------------------------------------------------------------------ # WRITE AHEAD LOG #------------------------------------------------------------------------------ wal_level = replica wal_buffers = 16MB max_wal_size = 2GB min_wal_size = 1GB checkpoint_completion_target = 0.9 #------------------------------------------------------------------------------ # REPLICATION #------------------------------------------------------------------------------ max_wal_senders = 2 wal_keep_segments = 32 #------------------------------------------------------------------------------ # QUERY TUNING #------------------------------------------------------------------------------ effective_cache_size = 4608MB #------------------------------------------------------------------------------ # RUNTIME STATISTICS #------------------------------------------------------------------------------ stats_temp_directory = '/var/run/postgresql/9.6-db_01.pg_stat_tmp' #------------------------------------------------------------------------------ # CLIENT CONNECTION DEFAULTS #------------------------------------------------------------------------------ datestyle = 'iso, dmy' timezone = 'localtime' lc_messages = 'ru_RU.UTF-8' # locale for system error message # strings lc_monetary = 'ru_RU.UTF-8' # locale for monetary formatting lc_numeric = 'ru_RU.UTF-8' # locale for number formatting lc_time = 'ru_RU.UTF-8' # locale for time formatting default_text_search_config = 'pg_catalog.russian' #------------------------------------------------------------------------------ # LOCK MANAGEMENT #------------------------------------------------------------------------------ max_locks_per_transaction = 300 # min 10 #------------------------------------------------------------------------------ # VERSION/PLATFORM COMPATIBILITY #------------------------------------------------------------------------------ escape_string_warning = off standard_conforming_strings = off #------------------------------------------------------------------------------ # CUSTOMIZED OPTIONS #------------------------------------------------------------------------------ online_analyze.threshold = 50 online_analyze.scale_factor = 0.1 online_analyze.enable = on online_analyze.verbose = off online_analyze.min_interval = 10000 online_analyze.table_type = 'temporary' plantuner.fix_empty_table = false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新たに作成されたクラスターを起動し、使用を開始します。

 # pg_ctlcluster 9.6 db_01 start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1C Enterpriseサーバーの管理のスナップインで非標準ポートを介して接続するには、「データベースサーバー」フィールドの情報ベースのパラメーターで指定します。



hostname port=5433







また、基地の定期的なメンテナンスを忘れないことも重要です。 VACUUMとANALYZEは非常に便利です。

ストリーミング複製

スタンバイサーバーの実装は非常に簡単です。



マスターサーバーをセットアップする

設定ファイルpostgresql.confを変更します。新しいクラスターを設定していることを忘れずに、ファイルは/etc/postgresql/9.6/db_01/にあります。



listen_addresses = '*'

wal_level = replica

max_wal_senders = 3

wal_keep_segments = 128







新しいレプリカロールを作成します。

 postgres=# CREATE ROLE replica WITH REPLICATION PASSWORD 'MyBestPassword' LOGIN;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pg_hba.confファイルを修正して、スレーブサーバーへの接続を許可します

 # TYPE DATABASE USER ADDRESS METHOD host replication replica 192.168.0.0/24 md5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、クラスターを再起動する必要があります。

 # pg_ctlcluster 9.6 db_01 restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、スレーブサーバーをセットアップします。 その構成がウィザードと同一であり、同じ名前のクラスターが作成され、データファイルがウィザードと同様にマウントされたディレクトリにあると仮定します。 スレーブ上のクラスターを停止しましょう：

 # pg_ctlcluster 9.6 db_01 stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

postgresql.confファイルで、スタンバイモードを有効にします。

hot_standby = on









/ databases / db_01 / slaveのデータファイルを含むディレクトリをクリアし、スレーブのウィザードの現在の状態のコピーを作成します。

 # cd /databases/db_01 # rm -Rf /databases/db_01 # su postgres -c "pg_basebackup -h master.domain.local -p 5433 -U replica -D /databases/db_01 -R -P --xlog-method=stream"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

recovery.confファイルが作成されます。必要に応じて修正してください。



standby_mode = 'on'

primary_conninfo = 'user=replica password=MyBestPassword host=master.domain.local port=5433 sslmode=prefer sslcompression=1 krbsrvname=postgres'







この場合、フェイルオーバーは行われません。これにより、マスターの役割が自動的に削除されます。 レプリカがウィザードとして動作を開始するには、recovery.confファイルの名前を変更してクラスターを再起動するだけです。



スレーブクラスタを実行します。

 # pg_ctlcluster 9.6 db_01 start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複製が進行中であることを確認します。 ウィザードにwal senderプロセスが表示され、スレーブにwal receiverが表示されます。 ウィザードを実行すると、レプリケーションに関する詳細情報を取得できます。

 SELECT *,pg_xlog_location_diff(s.sent_location,s.replay_location) byte_lag FROM pg_stat_replication s;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スレーブでは、最後の複製がいつ行われたかを示す値をたどることができます。

 SELECT now()-pg_last_xact_replay_timestamp();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

WALのバックアップとアーカイブ

最初は、1日1回pg_dumpを使用してバックアップを実行しました。これは、1C Freshのエリアをバックアップするための内部メカニズムとともに、許容可能なバックアップスキームを提供しました。 しかし、最後のバックアップの瞬間と事故の瞬間の間に多くの作業が行われた状況が時々あります。 これらの変更を失わないために、WALファイルのアーカイブが役立ちます。



WALアーカイブを有効にするには、3つの条件が満たされている必要があります。

Wal_levelはreplica以上に設定する必要があります

パラメーターarchive_mode = on

Archive_commandは、シェルコマンドを定義します。例：



archive_command = 'test ! -f /wal_backup/db_01/%f && cp %p /wal_backup/db_01/%f'







したがって、アーカイブされたWALセグメントをディレクトリ/ wal_backup / db_01 /にコピーします



変更を有効にするには、クラスターの再起動が必要です。 したがって、次のWALセグメントの準備ができたらコピーされますが、リカバリ中に使用するには、アーカイブされたWALセグメントからの変更が適用されるクラスターの基本コピーが必要です。 簡単なスクリプトを使用して、基本的なコピーを作成し、WALファイルの横に配置します。

 #!/bin/bash db="db_01" wal_arch="/wal_backup" datenow=`date '+%Y-%m-%d %H:%M:%S'` mkdir /tmp/pg_backup_$db su postgres -c "/usr/bin/pg_basebackup --port=5433 -D /tmp/pg_backup_$db -Ft -z -Xf -R -P" test -e ${wal_arch}/$db/base.${datenow}.tar.gz && rm ${wal_arch}/$db/base.${datenow}.tar.gz cp /tmp/pg_backup_$db/base.tar.gz ${wal_arch}/$db/base.${datenow}.tar.gz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一定期間（PiTR）のバックアップを復元するために、クラスターを停止し、コンテンツを削除します

 # pg_ctlcluster 9.6 db_01 stop # rm -Rf /databases/db_01
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、ベースコピーを解凍し、権限を確認し、次の内容でrecovery.confファイルを編集（または作成）します。



restore_command = 'cp /wal_backup/db_01/%f %p'

recovery_target_time = '2017-06-12 21:33:00 MSK'

recovery_target_inclusive = true









したがって、2017-06-12 21:33:00 MSKの時点でデータを復元し、ブレークポイントはこの時間に達した直後になります。

おわりに

戦闘操作では、1C FreshとPostgreSQLの束が価値があることが証明されました。もちろん、すべてがすぐにスムーズに進むわけではありませんが、私たちはそれを行いました。 DBMSは、約100人のユーザー、多くのバックグラウンドタスクおよびロボットによって生成される負荷の下で正常に機能し、昼夜を問わず抽出をダウンロードして実行し、他のツールからドキュメントを作成し、数千の領域の状態を分析します。



1C FreshとPostgreSQLの信頼性に関する写真：







350 GBを超える情報データベースがあり、すばらしいと感じ、成長し、発展しています。 私たちもあなたに何を願っています！