Repmgr käsijuhtimisel kasutamine

Allikas: Imre kasutab arvutit

Sissejuhatus

repmgr (Replication Manager for PostgreSQL) http://www.repmgr.org/ tarkvara on komplekt vaba tarkvaralisi vahendeid PostgreSQL andmebaasiklastri haldamiseks. Repmgr käsijuhtimisel kasutamisel

  • klaster koosneb kahest või enamast node'ist, mis töötavad master-standby režiimis (üks master, üks või enam standby node'i)
  • standby node lülitatakse master rolli ja master standby rolli (switcover, nt planeeritud hooldustöö)
  • standby node lülitatakse master rolli kui viimati master rollis olev arvuti riknes (failover, nt riistvara läks kakti)
  • rolle saab edasi muuta sõltuvalt asjaoludest mugavamalt või ebamugavamalt (switchover puhul mugav, failover puhul tõenäoliselt mitte nii mugav)

Seejuures on standby node master rolli lülitamisel kaks võimalust

  • switchover - planeeritud master-standby rollide vahetus, lülitus saab toimuda meelevaldne arv kordi, sobiv kasutada planeeritud hoolduse käigus
  • failover - planeerimata master-standby rollide vahetus, reeglina selliselt saab lülitus toimuda üks kord (ilma vahepeal pg_basebackup abil kogu baasi mahtu ümber kopeerimata)

Repmgr üldiselt sisaldab repmgr tutvustust ja on soovitav esmalt läbi vaadata.

Tööpõhimõte

Olgu repmgr käsijuhtimise kontrolli all üldiselt nt kolm PostgreSQL serverit (edasise teksti näidetes tegeldakse küll kahega)

           master                 standby                standby
          pg-rpm-1                pg-rpm-2               pg-rpm-3
     10.100.13.67:5432       10.100.13.68:5432      10.100.13.69:5432
            _____                   _____                  _____
           |     |                 |     |                |     |
           |     |                 |     |                |     |
           |_____|                 |_____|                |_____|
              |                       |                      |
              |                       |                      |
        ------|-----------------------|----------------------|-------------------

kus

  • igal node'il on oma lokaalne storage
  • korraga saab rakendus kasutada ainult ühte master režiimis töötavat node'i (standby on iseenesest read-only režiimis samuti kasutatav)
  • repmgr tarkvaraga seoses mingeid protsesse ei tööta
  • node'ide omavaheline suhtlemine toimub üle nö tavalise postgresql port 5432 tcp ühenduse + ssh (võtmetega autentimine)

Väited

  • repmgr kasutamise eelduseks on paigaldatud andmebaasi tarkvara; parem kasutada PGPDG repositooriumist v. 9.6, mis oskab pg_rewind kasutada (sellega saab switchover juhtumil master ja standby rolle korduvalt omavahel ümber lülitada)
  • repmgr kasutamine sobib lisada juurde juba kasutuses olevale baasile, st kui on andmed sees
  • master ja standby postgresql.conf ja pg_hba.conf failide sisu on ühesugune, seadistusfaile kasutatakse tavalisest Debiani /etc/postgresql/9.4/main kataloogist
  • oluline on protsessi vältel postgresqli protsesse käivitada jms systemctl utiliidiga ja mitte pg_ctl või pg_ctlcluster abil; osutub, et nt pg_ctlcluster abil käivitatud protesessi ei jäta systemctl seisma
  • repmgr kirjutab automaatselt standby arvutisse sobiva sisuga recovery.conf faili, nt
standby_mode = 'on'
primary_conninfo = 'user=repmgr host=10.100.13.68 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres application_name=''pg-rpm-2'''
recovery_target_timeline = 'latest'
primary_slot_name = repmgr_slot_2

Paigaldamine

  • lisada paketihaldusse tavaline apt PGDG repositoorium ja paigaldada andmebaas
# cat /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main
# apt-get update
# apt-get install pgdg-keyring
# apt-get update
# apt-get install postgresql-9.6

Seejuures tekib ja käivitatakse andmebaas

# pg_lsclusters 
Ver Cluster Port Status Owner    Data directory               Log file
9.6 main    5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log

PGDG repositooriumist saab 2017 aasta alguses paigaldada repmgr v. 3 öeldes

# apt-get install postgresql-9.6-repmgr

Tulemusena tekib failisüsteemi

  • /usr/share/doc/repmgr-common/README.md.gz
  • /etc/default/repmgrd
  • /usr/bin/repmgr
  • /usr/bin/repmgrd

Peale paigaldamist tuleb tekitada postgres kasutajate vahel ssh võtmega ligipääs

# su - postgres
$ mkdir .ssh
$ ssh-keygen

Ja kopeerida avalikud võtmed laiali ning logida risti-rästi arvutid läbi (nö yes ütlemiseks)

$ ssh postgres@10.100.13.68
...

Lisaks peab postgres kasutaja saama sudo abil root kasutajana öelda systemctl abil stop ja start PostgreSQL protsessidele jms. Selleks peab sudo seadistusfailis /etc/sudoers olema

Defaults:postgres !requiretty
postgres ALL = NOPASSWD: /bin/systemctl stop postgresql, \
       /bin/systemctl start postgresql, \
       /bin/systemctl restart postgresql, /bin/systemctl status postgresql

Testiks peab õnnestuma öelda lokaalselt

$ sudo /bin/systemctl status postgresql
...

Ning sarnaselt üle võrgu

$ ssh postgres@10.100.13.68 'sudo /bin/systemctl status postgresql'

Seadistamine

PostgreSQL tööd juhivad olulises osas kaks faili

  • /etc/postgresql/9.6/main/postgresql.conf - seadistatud streaming replication jms osa
  • /etc/postgresql/9.6/main/pg_hba.conf - seadistatud node'ide vaheline usaldus

ning repmgr utiliidi tööd fail

  • /etc/repmgr.conf

Ideid failis kasutatavate direktiivide kohta saab aadressilt https://github.com/2ndQuadrant/repmgr/blob/master/repmgr.conf.sample Käesolevas punktis tehtavaga ei kaasne repmgrd deemoni töö. repmgr tarkvara kasutatakse ainult tavalise PostgreSQL andmebaasi eksemplaride seadistamisel (sh baaside tabelitesse seadituste kirjutamisel, mis toimub automaatselt taustal) ja erinevate tegevuste käivitamisel (nt standby olekus baasi viimisel master olekusse).

PostgreSQL seadistusfailis postgresql.conf on kordistamise seisukohalt olulised sellised muudatused, teha mõlemas arvutis

 59c59
< #listen_addresses = 'localhost'               # what IP address(es) to listen on;
---
> listen_addresses = '*'                # what IP address(es) to listen on;
178c178
< #wal_level = minimal                  # minimal, replica, or logical
---
> wal_level = replica                       # minimal, replica, or logical
194c194
< #wal_log_hints = off                  # also do full page writes of non-critical updates
---
> wal_log_hints = on                    # also do full page writes of non-critical updates
216c216
< #archive_mode = off           # enables archiving; off, on, or always
---
> archive_mode = on             # enables archiving; off, on, or always
218c218
< #archive_command = ''         # command to use to archive a logfile segment
---
> archive_command = 'test ! -f /data/backup/postgresql/archive-logs/%f && cp %p /data/backup/postgresql/archive-logs/%f'
234c234
< #max_wal_senders = 0          # max number of walsender processes
---
> max_wal_senders = 10          # max number of walsender processes
236c236
< #wal_keep_segments = 0                # in logfile segments, 16MB each; 0 disables
---
> wal_keep_segments = 100               # in logfile segments, 16MB each; 0 disables
239c239
< #max_replication_slots = 0    # max number of replication slots
---
> max_replication_slots = 5     # max number of replication slots
257c257
< #hot_standby = off                    # "on" allows queries during recovery
---
> hot_standby = on                      # "on" allows queries during recovery

kus

  • wal_log_hints - oluline pg_rewind kasutamiseks
  • toodud seadistused arhiveerivad /data/backup/postgresql/archive-logs kataloogi PITR jaoks vajaliku wal logi

ja pg_hba.conf failis tuleb kasutada suhteliselt ees ridu, teha mõlemas arvutis (toodangu keskkonnas kasutamiseks peab ilmselt turvalisusele rohkem mõtlema)

local   replication   repmgr                              trust
host    replication   repmgr      127.0.0.1/32            trust
host    replication   repmgr      10.100.13.0/24          trust

local   repmgr        repmgr                              trust
host    repmgr        repmgr      127.0.0.1/32            trust
host    repmgr        repmgr      10.100.13.0/24          trust

kus

  • TODO

Andmebaasi tuleb tekitada superuser privileegiga kasutaja repmgr ning create database repmgr tema omandusse, ainult masteris kuna standby peale see kopeeritakse

$ createuser -s repmgr
$ createdb repmgr -O repmgr

Muudatuste kehtestamiseks öelda baasi protsessidele restart, ainult masteris

# systemctl restart postgresql

Lisaks muuta repmgr kasutaja search path, ainult masteris

SQL> ALTER USER repmgr SET search_path TO repmgr_test, "$user", public;

repmgr seadisusfailis /etc/repmgr.conf sobib kasutada sellist sisu, ühesugune mõlemas v.a. kolme parameetri osas erinev, standby osa vt alt poolt 'Standby ettevalmistamine' punktist

cluster = 'test'
# erinevatel nodeidel erinevad vaartused
node = 1
node_name = 'pg-rpm-1'
 
# kuidas saab kohalikule serverile ligi
conninfo = 'host=10.100.13.67 user=repmgr dbname=repmgr'
 
use_replication_slots = 1

pg_bindir = /usr/lib/postgresql/9.6/bin

# loglevel = DEBUG

service_start_command = sudo /bin/systemctl start postgresql
service_stop_command = sudo /bin/systemctl stop postgresql
service_restart_command = sudo /bin/systemctl restart postgresql
service_reload_command = pg_ctlcluster 9.6 main reload
service_promote_command = pg_ctlcluster 9.6 main promote

kus

  • postgresql start, stop ja restart öeldakse systemd abil root kasutajana
  • reload ja promote öeldakse pg_ctlcuster abil postgres kasutajana

Master ettevalmistamine

Eelduseks on et baasi protsessid töötavad ning eelmistes punktides tehtud seadistuste muudatused on kehtestatud. Master baasis sobib kordistamise võime sisselülitamiseks öelda

$ repmgr -f /etc/repmgr.conf master register
NOTICE: master node correctly registered for cluster test with id 1 (conninfo: host=10.100.13.67 user=repmgr dbname=repmgr)

Kontrolliks küsida, tabel on repmgr baasis, skeemis repmgr_klastrinimi

$ psql repmgr
repmgr=# \x
Expanded display is on.

repmgr=# SELECT * FROM repmgr_test.repl_nodes;
-[ RECORD 1 ]----+--------------------------------------------
id               | 1
type             | master
upstream_node_id | 
cluster          | test
name             | pg-rpm-1
conninfo         | host=10.100.13.67 user=repmgr dbname=repmgr
slot_name        | repmgr_slot_1
priority         | 100
active           | t

Standby ettevalmistamine

Standby peal ei ole vaja CREATE ROLE ega CREATE DATABASE öelda kuna standby ettevalmistamisel kopeerib repmgr kogu baasi masterist üle. Andmebaasi tarkvara peab olema paigaldatud ja protsessid ei tohi töötada.

Standby seadistusfail on sama nagu master, erineb kolme parameetri väärtuste osas osas

node = 2
node_name = pg-rpm-2
conninfo = 'host=10.100.13.68 user=repmgr dbname=repmgr'

Kustutada andmete kataloog

$ rm -rf /var/lib/postgresql/9.6/main

Masterist andmete kopeerimiseks öelda

$ repmgr -f /etc/repmgr.conf -h 10.100.13.70 -U repmgr -d repmgr -D /var/lib/postgresql/9.6/main standby clone
NOTICE: destination directory '/var/lib/postgresql/9.6/main' provided
NOTICE: starting backup (using pg_basebackup)...
HINT: this may take some time; consider using the -c/--fast-checkpoint option
NOTICE: standby clone (using pg_basebackup) complete
NOTICE: you can now start your PostgreSQL server
HINT: for example : pg_ctl -D /var/lib/postgresql/9.6/main start
HINT: After starting the server, you need to register this standby with "repmgr standby register"

kus

  • TODO

Seejärel käivitada standby andmebaasi protssessid

# systemctl start postgresql

Kontrollida, mis masteris paistab

$ psql repmgr
repmgr=# \x

Expanded display is on.
repmgr=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 12789
usesysid         | 16384
usename          | repmgr
application_name | pg-rpm-1
client_addr      | 10.100.13.67
client_hostname  | 
client_port      | 57626
backend_start    | 2017-01-28 18:31:02.064805+00
backend_xmin     | 
state            | streaming
sent_location    | 0/40001A8
write_location   | 0/40001A8
flush_location   | 0/40001A8
replay_location  | 0/40001A8
sync_priority    | 0
sync_state       | async

Standby registreerimine klastrisse, ainult standby arvutis

$ repmgr -f /etc/repmgr.conf standby register
NOTICE: standby node correctly registered for cluster test with id 2 (conninfo: host=10.100.13.68 user=repmgr dbname=repmgr)

Tulemusena peab paistama mõlemast arvutist selline vastus (oluline on standby rollis oleva baasi juures upstream_node_id väärtus '1')

repmgr=#  SELECT * FROM repmgr_test.repl_nodes;
 id |  type   | upstream_node_id | cluster |      name      |                  conninfo                   |   slot_name   | priority | active 
----+---------+------------------+---------+----------------+---------------------------------------------+---------------+----------+--------
  1 | master  |                  | test    | pg-rpm-1       | host=10.100.13.67 user=repmgr dbname=repmgr | repmgr_slot_1 |      100 | t
  2 | standby |                1 | test    | pg-rpm-2       | host=10.100.13.68 user=repmgr dbname=repmgr | repmgr_slot_2 |      100 | t
(2 rows)

Kontroll

  • Mõlemas arvutis peaks saama sarnase vastuse
$ repmgr cluster show
Role      | Name           | Upstream       | Connection String
----------+----------------|----------------|--------------------------------------------
* master  | pg-rpm-1       |                | host=10.100.13.67 user=repmgr dbname=repmgr
  standby | pg-rpm-2       | pg-rpm-1       | host=10.100.13.68 user=repmgr dbname=repmgr
  • tekitades masterisse create database baasi või create role kasutaja ilmub ta ka standby peale
  • püüdes standby peal tekitada baasi öeldakse
postgres=# create database imre7;
ERROR:  cannot execute CREATE DATABASE in a read-only transaction

Haldusprotseduurid

  • switchover - planeeritud master-standby rollide ümbervahetamine
  • failover - planeerimata master-standby rollide ümbervahetamine (masteri tuum krahhis)

Master-standby rollide vahetamine - switchover

Öelda standby arvutis, tulemusena on standby master ja master standby, seejuures kasutatakse pg_rewind tehnikat

$ repmgr -f /etc/repmgr.conf -C /etc/repmgr.conf standby switchover -v
NOTICE: using configuration file "/etc/repmgr.conf"
NOTICE: switching current node 2 to master server and demoting current master to standby...
NOTICE: 0 files copied to /tmp/repmgr-pg-rpm-1-archive
NOTICE: current master has been stopped
ERROR: connection to database failed: could not connect to server: Connection refused
        Is the server running on host "10.100.13.67" and accepting
        TCP/IP connections on port 5432?

NOTICE: promoting standby
NOTICE: promoting server using 'pg_ctlcluster 9.6 main promote'
NOTICE: STANDBY PROMOTE successful
NOTICE: Executing pg_rewind on old master server
NOTICE: 0 files copied to /var/lib/postgresql/9.6/main
NOTICE: restarting server using 'sudo /bin/systemctl restart postgresql'
NOTICE: node 1 is replicating in state "streaming"
NOTICE: replication slot "repmgr_slot_2" deleted on former master
NOTICE: switchover was successful

Seejärel saab uue standby peal sarnaselt öelda ja nii kuitahes palju kordi rolle omalvahel loksutada. pg_rewind nö wal-logide-sisene-rsync võtab kasutausele järgmisel timeline history jns, kogu andmefailide kataloogi ümber ei kopeerita. Väga mugav ja kiire kasutada suurte andmemahutudega.

Master-standby rollide vahetamine - failover

Kui master riknes ja seda taastada piisavalt kiiresti ei ole võimalik, siis tuleb tagada, et vana master mingil põhjusel ise ei käivituks uuesti vms ja standby lülitatakse iseseisvalt masteriks

$ repmgr -f /etc/repmgr.conf standby promote
ERROR: connection to database failed: could not connect to server: Connection refused
        Is the server running on host "10.100.13.67" and accepting
        TCP/IP connections on port 5432?

NOTICE: promoting standby
NOTICE: promoting server using 'pg_ctlcluster 9.6 main promote'
NOTICE: STANDBY PROMOTE successful

Tulemusena klastri olukord paistab selline

$ repmgr cluster show
Role      | Name            | Upstream | Connection String
----------+-----------------|----------|------------------------------------------------------
  FAILED  | pg-rpm-1        |          | host=10.100.13.67 user=repmgr dbname=repmgr
* master  | pg-rpm-2        |          | host=10.100.13.68 user=repmgr dbname=repmgr
Hävinenud master standby rolli - clone abil

Kunagi hiljem hävinud masteri juurutamiseks standby rolli sobib

  • veenduda, et postgres protsessid ei tööta
  • kustutada andmekataloog
$ rm -rf /var/lib/postgresql/9.6/main
  • kopeerida andmed masterist üle
$ repmgr -f /etc/repmgr.conf -h 10.100.13.68 -U repmgr -d repmgr -D /var/lib/postgresql/9.6/main standby clone
NOTICE: destination directory '/var/lib/postgresql/9.6/main' provided
NOTICE: starting backup (using pg_basebackup)...
HINT: this may take some time; consider using the -c/--fast-checkpoint option
NOTICE: standby clone (using pg_basebackup) complete
NOTICE: you can now start your PostgreSQL server
HINT: for example : pg_ctl -D /var/lib/postgresql/9.6/main start
HINT: After starting the server, you need to register this standby with "repmgr standby register"
  • käivitada
# systemctl start postgresql
  • re-registreerida
$ repmgr -F -f /etc/repmgr.conf standby register
NOTICE: standby node correctly registered for cluster test with id 2 (conninfo: host=10.100.13.67 user=repmgr dbname=repmgr)

Tulemusena on töötav klaster jällegi koos

$ repmgr cluster show
Role      | Name            | Upstream | Connection String
----------+-----------------|----------|------------------------------------------------------
  standby | pg-rpm-1        | pg-rpm-1 | host=10.100.13.67 user=repmgr dbname=repmgr
* master  | pg-rpm-2        |          | host=10.100.13.68 user=repmgr dbname=repmgr
Oma teed läinud master standby rolli - pg_rewind abil

Kui master käis edasi peale seda kui standby promotes ennast masteriks, talle tehti stop ja start jne, siis mõlemad serverid on arenenud oma teed, toimunud on aus split brain (nt selle switchi port, kuhu master on ühendatud läks rikki ja standby vaatas, et witness on näha, masterit pole näha ja promotes ausalt ennast masteriks + rakendused asusid teda kasutama). Split braini saab lahendada põhimõtteliselt kahel viisil

  • uurida vana masterit ja käsitsi kanda üle vajalikud muudatused uude masterisse; ning seejärel unustada vana master ja sünkida uuest masterist muudatused ning kasutada teda edasi standby rollis
  • uurida vana masterit, jõuda järeldusele, et võib ta unustada ja sünkida uuest masterist muudatused ning kasutada teda edasi standby rollis

Peale otsust, et nüüd võib moel või teisel vana masteri sisu unustada, lõpetada seal postgres protsessid. Ja sünkida pg_rewind abil uue masteri pealt seis, seejuures rakendub pg_rewind ime abil, et kopeeritakse vaid failisüsteemi suhtes muudatused (mitte ei toimu base backup)

$ /usr/lib/postgresql/9.6/bin/pg_rewind --target-pgdata=/var/lib/postgresql/9.6/main --source-server="host=10.100.13.70 user=postgres dbname=postgres"
servers diverged at WAL position 0/2D000098 on timeline 22
rewinding from last common checkpoint at 0/2D000028 on timeline 22
Done!

kus

  • --source-server - master host
  • postgres kasutaja peab ligi pääsema
  • --target-pgdata=... - käesolevas arvutis asuvad andmedfailid

Lisaks tuleb moodustada sobiva sisuga recovery.conf, nt

$ cat /var/lib/postgresql/9.6/main/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=repmgr host=10.100.13.70 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres application_name=''imre-pm-1-ns'''
recovery_target_timeline = 'latest'
primary_slot_name = repmgr_slot_1

kus

  • host= ... - masteri hostname
  • application_name = ... - käesoleva standby hosti nimi (millega ta on registreeritud repl_nodes tabelis
  • primary_slot_name = ... - nimi millega käesoleva hosti slot nimi on registreeritud repl_nodes tabelis

Seejärel käivitada postgres protsessid. Millegipärast on vaja vist standby re-registreerida

$ repmgr -F -f /etc/repmgr.conf standby register
NOTICE: standby node correctly registered for cluster test with id 2 (conninfo: host=10.100.13.67 user=repmgr dbname=repmgr)

Kokkuvõttes vaadata ka repl_nodes tabel üle

SQL> select * from repmgr_test.repl_nodes;

Misc

  • tundub, et standby seisma jätmine ja uuesti käivitamine on ok
  • tundub, et standby crash ja uuesti käivitamine on ok
  • tundub, et master seisma jätmine ja uuesti käivitamine on ok
  • tundub, et master crash ja uuesti käivitamine on ok
  • tundub, et postgresql baasi minor versiooni uuendust saab teha enne standby ja siis master ja nn base backup ei ole vajalik
  • tundub, et postgresql baasi major versiooni uuenduseks tuleb esmalt teha master ja seejärel standby juurutada base backup abil
  • kui standby lülitatakse ümber masteriks nii et vana master crashib, siis vana masteri kasutamiseks baasina ei ole muud võimalust kui nö pg_basebackup

Kui klastri node'ide olekute üle on repl_nodes tabel segaduses, siis võib olla abi selle käsitsi kohendamisest, nt

SQL> select * from repmgr_test.repl_nodes;
SQL> update repmgr_test.repl_nodes set type='standby' where id=1;
SQL> update repmgr_test.repl_nodes set upstream_node_id=1 where id=2;
SQL> update repmgr_test.repl_nodes set active='t' where id=1;

Lisaks võib olla vaja moodustada ka replication slot

SQL> select * from pg_create_physical_replication_slot('repmgr_slot_1');
SQL> select * from pg_replication_slots;

Lisaks võivad olla master ja standby repmgr baasis repl_nodes tabelid erineva sisuga, ühtlustamiseks sobib öelda midagi nö üle master peal.

Seire

Lisada /etc/repmgr.conf faili rida

failover=manual

ning käivitada sedasi

$ repmgrd -f /etc/repmgr.conf -m -v

Tulemusena täitub tabel repmgr_test.repl_status

repmgr=# select * from repmgr_test.repl_status;
-[ RECORD 1 ]-------------+--------------------------------------
primary_node              | 2
standby_node              | 1
standby_name              | imre-pm-1-ans2
node_type                 | standby
active                    | t
last_monitor_time         | 2017-02-07 19:01:53.767952+00
last_wal_primary_location | 0/390247C8
last_wal_standby_location | 0/390247C8
replication_lag           | 0 bytes
replication_time_lag      | 00:00:03.003645
apply_lag                 | 0 bytes
communication_time_lag    | 17 years 1 mon 6 days 19:01:54.258192

Seda saab

  • kasutada, et hinnata kui hästi püsib standby masteri kannul
  • switchover puhul veenduda, et kõik masteris tehtud muudatused on jõudnud kohale standby peale

Klastri kasutamine

Käsijuhtimisel töötava klastri kasutamise iseloomuga sobib tõenäoliselt, et peale master rolli ümberpaigutumist teisse arvutisse

  • rakendusserveris seadistatakse rakendus kasutama teist ip aadressi
  • rakendusserveri paketifiltri abil suunatakse liiklus teisele ip aadressile
  • andmebaaside vahel eemaldadatakse vanalt ja seadistatakse käsitsi vip aadress uue master arvuti peale (nn eth0:0 liidese aadress)

Kasulikud lisamaterjalid