Кластеры SQL серверов - 2

Sunday, October 29, 2006

откуда - the lock table & Transaction Inventory Page

1) доступ к the lock table - из lock manager
2) доступ к Transaction Inventory Page - это просто страница базы (файла базы)

the lock table

Firebird, however, manages its locks in a shared memory section. In SuperServer, only the server uses that share memory area. In Classic, every database connection maps the shared memory and every connection can read and change the contents of the memory.

The lock table is a separate piece of share memory. In SuperServer, the lock table is mapped into the server process. In Classic, each process maps the lock table. All databases on a server computer share the same lock table, except those running with the embedded server.

Firebird locking summary

Although Firebird does not lock records, it uses locks extensively to isolate the effects of concurrent transactions. Locking and the lock table are more visible in Firebird than in other databases because the lock table is a central communication channel between the separate processes that access the database in Classic mode. In addition to controlling access to database objects like tables and data pages, the Firebird lock manager allows different transactions and processes to notify each other of changes to the state of the database, new indexes, etc.

Firebird lock manager

We often talk about the Firebird Lock Manager as if it were a separate process, but it isn’t. The lock management code is part of the engine, just like the optimizer, parser, and expression evaluator. There is a formal interface to the lock management code, which is similar to the formal interface to the distributed lock manager that was part of VAX/VMS and one of the interfaces to the Distributed Lock Manager from IBM.

The lock manager is code in the engine. In Classic, each process has its own lock manager. When a Classic process requests or releases a lock, its lock management code acquires a mutex on the shared memory section and changes the state of the lock table to reflect its request.

Transaction Inventory Page

Transaction Inventory Page

Page Type 3 is a transaction information page (TIP). The TIP header includes the address of the next TIP.

The body of a TIP is an array of pairs of bits that reflect the state of transactions. If both bits are 0, the transaction is active or has not started. If both bits are 1, the transaction is committed. If the first bit is 1 and the second bit is 0, the transaction rolled back. If the first bit is 0 and the second is 1, the transaction is in limbo.

Limbo is the state of a two phase transaction that has completed the first phase, but not the second.

Saturday, October 28, 2006

делать по одной штуке!

Самое замечательное во всей этой штуке - то, что можно вытаскивать по одной штуке - и отлаживать :
- вывели запись страниц данных через внешний канал - и сервер все равно не почуствует - будет работать (и зеркало можно сделать)

Что хотим получить?

Хотим получить поведение кластера - аналогично поведению одного сервера.

Стандартный цикл пишущей транзакции:
- старт транзакции
- (что то пишем) проверка констрейна
- запись страницы данных (измененной)
- (все зделали) коммит/роллбак

(для простоты пока не рассматриваем триггера)
------------
как хотим сделать:
- старт транзакции
- запись страницы данных
- коммит/роллбак

- (+) запись в таблицу блокировок
- (+) запись в Transaction Inventory Page, TIP

все это через один канал (допустим через адреса другой подсети) - паралельно во все сервера.
--------------
остается разобраться
1) с блокировками при проверках констрейнов ?
2) с адресами (поскольку на данном сервере будут стартовать транзакции с других серверов, писать блокировки другие сервера) ?
3) Sweep собирает мусорные версии записей - как с этим?

Friday, October 27, 2006

анонс - сырой пока

вторая итерация - кластеров скл серверов.

тема: постраничная репликация.

1) пишем постранично во все сервера паралельно
2) делаем общую таблицу блокировок
3) (тут туманно) нужно проверить - алгоритм постраничной записи - что проверять для щастья (сохранения синхронизма по серверам, сохранения базы - соответствия констрейнам и т.д.)