MaterializeInc / tb

Tail the Binlog of a database
Apache License 2.0
15 stars 2 forks source link

Troubleshooting guide #28

Open 3noch opened 4 years ago

3noch commented 4 years ago

I tried this out recently but my materialized view always yields 0 rows when queried. However it seems to understand the schema of the source just fine so it's obviously connected in some fashion. I'm just not sure how to troubleshoot it. I was using docker for everything with mounted volumes to share the data.

quodlibetor commented 4 years ago

This sounds like something that we should put into our operations guide at https://materialize.io/docs/ops .

The first things to check are the docker logs for materialized and tb.

However it seems to understand the schema of the source just fine so it's obviously connected in some fashion.

Does this mean that SHOW SOURCES and SHOW SOURCE foo look correct? You can try running the dashboard to get an overview of what materialized is doing, something might be surprising there.

3noch commented 4 years ago

Yes as far as I can tell everything looks fine on the source. But create a materialized view from that source (or even creating a materialized source instead) always yields 0 rows. It's a very small table with only 2 columns and 3 rows. Is it possible I'm hitting #24 even though the table is already populated by the time I create the source?

3noch commented 4 years ago

I don't know what to look for in the dashboard that would clue me in to a problem.

quodlibetor commented 4 years ago

Is it possible I'm hitting 24 even though the table is already populated by the time I create the source?

It's possible, although very unlikely. You can check if the files that the sources read from by looking at the files that you specify in the CREATE SOURCE statement, they're binary files, but text data from your database should be readable. At the very least, there should be data after the header line, if there's no data after the header (which is a json document describing the schema) then there is an issue with tb, otherwise the issue is probably in materialized.

I don't know what to look for in the dashboard that would clue me in to a problem.

The most interesting thing would be the number of arrangement or records. If both of those are zero then no data has ever made it into materialize, if they're above zero then it is likely that something in your materialized view is filtering out all the data.

Something else worth trying is just creating a materialized source with CREATE MATERIALIZED SOURCE ... and selecting from that. It should always return either results or an explicit error about data not being fully loaded yet.

3noch commented 4 years ago

I tried CREATE MATERIALIZED SOURCE and even that gave back zero rows. Also the dashboard showed that there were many thousands of "records" (what that means I'm not sure). The Kafka ingest etc counters were all 0.

3noch commented 4 years ago

The files in /tmp/tbshare seem to have header-ish information only but no data that is in my table. I wonder if it's silently failing due to write permissions or something like that.

3noch commented 4 years ago

In case it's helpful:

I'm running postgresql via their latest docker image 62473370e7ee.

With this schema:

postgres=# \d+ names
                                                Table "public.names"
 Column |  Type   | Collation | Nullable |              Default              | Storage  | Stats target | Description 
--------+---------+-----------+----------+-----------------------------------+----------+--------------+-------------
 pk     | integer |           | not null | nextval('names_pk_seq'::regclass) | plain    |              | 
 name   | text    |           | not null |                                   | extended |              | 
Publications:
    "dbz_publication"
Replica Identity: FULL
Access method: heap

postgres=# SHOW wal_level;
 wal_level 
-----------
 logical
(1 row)

postgres=# SELECT COUNT(*) from names;
 count 
-------
     3
(1 row)
quodlibetor commented 4 years ago

@3noch it seems likely that you ran into #24 , and the most recent tb release in docker might fix it.